From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0001.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0002.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0003.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0001.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0005.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0002.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0001.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0006.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0003.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0002.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0007.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0004.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0003.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0001.html From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0008.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0005.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0005.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0002.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0002.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0002.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0002.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0009.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0006.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0006.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0003.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0003.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0003.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0003.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0010.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0007.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0007.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0004.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0004.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0004.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0004.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment.html From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0011.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0008.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0008.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0005.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0005.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0005.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0005.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0001.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0001.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0012.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0009.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0009.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0006.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0006.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0006.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0006.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0003.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0002.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0002.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0013.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0010.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0010.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0007.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0007.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0007.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0007.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0004.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0003.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0003.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0014.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0011.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0011.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0008.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0008.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0008.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0008.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0005.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0004.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0004.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0015.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0012.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0012.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0009.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0009.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0009.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0009.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0006.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0005.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0005.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0016.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0013.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0013.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0010.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0010.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0010.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0010.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0007.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0006.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0006.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0017.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0014.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0014.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0011.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0011.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0011.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0011.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0008.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0007.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0007.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0002.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0018.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0015.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0015.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0012.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0012.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0012.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0012.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0009.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0008.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0008.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0003.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0019.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0016.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0016.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0013.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0013.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0013.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0013.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0010.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0009.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0009.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0004.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0001.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0020.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0017.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0017.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0014.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0014.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0014.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0014.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0011.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0010.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0010.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0005.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0002.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0002.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0001.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0001.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0001.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0001.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0001.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0021.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0018.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0018.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0015.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0015.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0015.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0015.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0012.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0011.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0011.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0006.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0003.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0003.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0003.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0002.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0002.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0002.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0002.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0002.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0002.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0002.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0022.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0019.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0019.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0016.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0016.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0016.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0016.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0013.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0012.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0012.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0007.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0004.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0004.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0004.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0003.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0003.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0003.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0003.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0003.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0003.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0003.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0001.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0023.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0020.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0020.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0017.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0017.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0017.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0017.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0014.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0013.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0013.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0008.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0005.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0005.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0005.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0004.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0004.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0004.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0004.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0004.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0004.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0004.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0002.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0024.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0021.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0021.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0018.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0018.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0018.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0018.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0015.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0014.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0014.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0009.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0006.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0006.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0006.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0005.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0005.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0005.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0005.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0005.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0005.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0005.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0003.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0025.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0022.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0022.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0019.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0019.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0019.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0019.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0016.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0015.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0015.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0010.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0007.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0007.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0007.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0006.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0006.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0006.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0006.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0006.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0006.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0006.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0004.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0026.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0023.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0023.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0020.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0020.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0020.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0020.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0017.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0016.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0016.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0011.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0008.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0008.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0008.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0007.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0007.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0007.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0007.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0007.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0007.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0007.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0006.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0027.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0024.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0024.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0021.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0021.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0021.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0021.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0018.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0017.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0017.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0012.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0009.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0009.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0009.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0008.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0008.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0008.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0008.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0008.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0008.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0008.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0007.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0028.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0025.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0025.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0022.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0022.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0022.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0022.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0019.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0018.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0018.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0013.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0010.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0010.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0010.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0009.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0009.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0009.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0009.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0009.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0009.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0009.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0008.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0002.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0029.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0026.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0026.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0023.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0023.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0023.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0023.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0020.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0019.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0019.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0014.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0011.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0011.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0011.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0010.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0010.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0010.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0010.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0010.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0010.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0010.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0009.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0003.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0001.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0001.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0030.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0027.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0027.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0024.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0024.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0024.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0024.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0021.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0020.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0020.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0015.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0012.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0012.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0012.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0011.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0011.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0011.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0011.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0011.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0011.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0011.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0010.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0004.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0003.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0003.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment-0002.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0031.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0028.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0028.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0025.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0025.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0025.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0025.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0022.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0021.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0021.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0016.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0013.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0013.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0013.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0012.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0012.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0012.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0012.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0012.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0012.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0012.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0011.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0005.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0004.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0004.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment-0003.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0032.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0029.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0029.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0026.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0026.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0026.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0026.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0023.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0022.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0022.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0017.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0014.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0014.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0014.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0013.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0013.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0013.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0013.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0013.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0013.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0013.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0012.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0006.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0005.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0005.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment-0004.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0033.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0030.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0030.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0027.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0027.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0027.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0027.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0024.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0023.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0023.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0018.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0015.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0015.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0015.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0014.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0014.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0014.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0014.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0014.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0014.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0014.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0013.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0007.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0006.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0006.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment-0005.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0034.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0031.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0031.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0028.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0028.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0028.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0028.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0025.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0024.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0024.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0019.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0016.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0016.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0016.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0015.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0015.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0015.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0015.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0015.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0015.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0015.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0014.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0008.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0007.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0007.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment-0006.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0035.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0032.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0032.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0029.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0029.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0029.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0029.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0026.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0025.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0025.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0020.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0017.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0017.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0017.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0016.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0016.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0016.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0016.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0016.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0016.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0016.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0015.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0009.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0008.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0008.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment-0007.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0036.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0033.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0033.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0030.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0030.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0030.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0030.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0027.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0026.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0026.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0021.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0018.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0018.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0018.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0017.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0017.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0017.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0017.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0017.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0017.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0017.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0016.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0010.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Wed Feb 27 16:48:14 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 18:48:14 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5E9D9.9030004@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> Message-ID: <47C5F6BE.8040809@gatworks.com> its, on most unix's, created automagically. When u plug in the device, the kernel/usb subsystem will ( attempt to ) recognze the device and install the appropriate device driver. It might also install the usb-serial device driver also. All done automagically. U can observe the transaction in the kernel log file /var/log/messages. Device major and minor device id's are enabled for that device. On the user side, a program is awaken ( i dont know which ) and reads its config table, and creates /dev/ttyUSBx, usually owned by uucp. if you dont see /dev/ttyUSB* then look in the kernel logfile. mirek wrote: > hello > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > From Noel.Goldsmith at dsto.defence.gov.au Wed Feb 27 17:49:26 2008 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Thu, 28 Feb 2008 11:49:26 +1100 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: Message-ID: Hi, I have just installed Leopard (10.5.2) on a Macpro dual 4 core machine with 9Gb RAM. Then I installed RXTX 2.1-7r2 on the Mac using the Tiger install. And created the uucp directory etc, as I do for machines running 10.4 xx. At first it did not work, said the port was not available, so I perused this list and found out about the lock file problem. Viz snip 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 Snip Which works very nicely. My thanks go to the creators and supporters of this nice piece of work. Now my question. If I go to the trouble of installing X-CODE, learning how to CVS and do all that, will the 2.1.8 code still require the lock directory fix? Or will I just leave things as they are until the Binary is finalized? Thank you Noel -- Noel Goldsmith DSTO 506 Lorimer Street Port Melbourne Victoria Australia 3207 Phone 613 96267527 Mobile 0428364003 Fax 613 96267718 Email noel.goldsmith at dsto.defence.gov.au IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ajmas at sympatico.ca Wed Feb 27 18:43:52 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:43:52 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <3EEDB6E7-94BB-426C-86C7-8690D22BB6F2@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > > > Thanks!!! It works :-) I'll have to take the actual build result for a > spin tomorrow. > > Why isn't this part of the "official" rxtx repository? If these changes do indeed make the Windows build simpler, then it would be nice to see this merged with official stream if it doesn't break anything. In the meantime I have added the two links to the build notes for Windows in the Wiki. Andre From drfaygo at gmail.com Wed Feb 27 18:44:04 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 20:44:04 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <748d0ca90802271744x49ed6979ycf190280a7f0b11@mail.gmail.com> I think the only case you would have to create the device files manually is if you are not using devfs or udev. In which case you can do: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 ... I agree, look at /var/log/messages (you can use dmesg) and see if the kernel is at least detecting your hardware (unplug and plug the dongle in, you should see a message) If not, either the module for your usb-serial converter is not installed, or if you don't use modules, you need to compile the driver into the kernel. It took me a few tries before I figured out the right driver for my radioshack usb-serial converter. good luck -Paul On Wed, Feb 27, 2008 at 6:48 PM, gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > > mirek wrote: > > hello > > > > can you give me some howto, how to create a /dev/ttyUSBx device? i am > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Feb 27 18:48:59 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:48:59 -0500 Subject: [Rxtx] : RE RXTX on Leopard 10.5.2 In-Reply-To: References: Message-ID: <4AE6F7DF-7DC7-414A-BD4A-5D02166D5703@sympatico.ca> On 27-Feb-08, at 19:49 , Goldsmith, Noel wrote: > Now my question. > If I go to the trouble of installing X-CODE, learning how to CVS and > do all > that, will the 2.1.8 code still require the lock directory fix? > Or will I just leave things as they are until the Binary is finalized? > Thank you > Noel If you get the latest code from CVS, then this issue has been resolved: Retrieving: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code Building: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Andre From ajmas at sympatico.ca Wed Feb 27 18:53:43 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 20:53:43 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > (Clearly this was for the list :-) > > On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet > wrote: >> Hi, >> You might find this useful: >> >> http://www.codeskin.com/c2oooProg_faq.html#rxtx >> >> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile > Do the instructions for building with CDT require the patched Makefile to work - I am not on Windows, so I can't check this. I have added a copy of your instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT Please could you update them as necessary. Thanks Andre From beat.arnet at gmail.com Wed Feb 27 19:08:17 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 27 Feb 2008 21:08:17 -0500 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> References: <0B7D47B9-FC58-49C3-B825-0A2D35026F82@sympatico.ca> Message-ID: <47C61791.1090305@gmail.com> Andre-John Mas wrote: > > On 27-Feb-08, at 15:57 , ?yvind Harboe wrote: > >> (Clearly this was for the list :-) >> >> On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet >> wrote: >>> Hi, >>> You might find this useful: >>> >>> http://www.codeskin.com/c2oooProg_faq.html#rxtx >>> >>> http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile >>> >> > > Do the instructions for building with CDT require the patched Makefile to > work - I am not on Windows, so I can't check this. > > I have added a copy of your instructions here: > > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows#Building_with_Eclipse.2FCDT > > > Please could you update them as necessary. > > Thanks > > Andre > Andre, Thanks for adding the instructions to the Wiki (I made some small adjustments). The "patch" refers to some changes that I made to rxtx in how the DTR line is controlled. The unpatched original version (2.1.7) is available here: http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2 My only contribution to this branch is the makefile. Regards, Beat From ajmas at sympatico.ca Wed Feb 27 19:15:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:15:02 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: On 27-Feb-08, at 11:43 , paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? In short: yes. I do this with my GPS devices, one which uses a usb-to-serial and the other Bluetooth. The real magic depends on your system level drivers. If the drivers are correctly configured then you should see some extra serial ports (COM, /dev/tty). RXTX will simply use these. If you are running into any issues please let us know your set up. Andre From ajmas at sympatico.ca Wed Feb 27 19:18:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Feb 2008 21:18:04 -0500 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows In-Reply-To: References: Message-ID: On 27-Feb-08, at 16:37 , Lawrence J. Miller wrote: > My Java program that uses rxtx does not find com ports that have been > added to a windows system with a Prolific usb dongle. The ports show > up in device manager, and other win32 apps. My program is a command- > line and runs in Java under cmd.exe. My program does find COM1, which > is on the system motherboard. Does anyone have any ideas on how to get > rxtx to find those additional com ports? I don't have Windows in front of me, but I believe there is probably a setting in of the device, in the device manager. These instruction might do the job: http://www.beaglesoft.com/232usb.htm Andre From mirek at host.sk Thu Feb 28 04:49:19 2008 From: mirek at host.sk (mirek) Date: Thu, 28 Feb 2008 12:49:19 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C5F6BE.8040809@gatworks.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> Message-ID: <47C69FBF.7010504@host.sk> ok - so - when i try to plug my device (combination of ds2490 and ds9490 and ds1408 i think (temperature sensor)), this is, what happend: - the module ds2490 is loaded. if i want to use digitemp, i need to unload this module, because it doesnt work with - anyway - no /dev/ttyUSB* created - after loading ds2490 module to the kernel, this is the dmesg result: [ 1261.628000] usb 4-1: USB disconnect, address 3 [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and address 4 [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice [ 1287.660000] Driver for 1-wire Dallas network protocol. [ 1287.760000] usbcore: registered new interface driver DS9490R - the device is loaded to the /dev/bus/usb/001/001 so - yes - all is done automaticaly, but not the way i need to :-( i am using ubuntu 7.10 (the same result are with the desktop and server edition). i would like to use 1-wire api from maxim dallas in combination with the rxtx libraries, but cannot make it work with the usb port :-( any other suggestions? i will appreciate your help... mirek gat wrote: > its, on most unix's, created automagically. When u plug in the device, > the kernel/usb subsystem will ( attempt to ) recognze the device and > install the appropriate device driver. It might also install the > usb-serial device driver also. All done automagically. U can observe the > transaction in the kernel log file /var/log/messages. Device major and > minor device id's are enabled for that device. > On the user side, a program is awaken ( i dont know which ) and reads > its config table, and creates /dev/ttyUSBx, usually owned by uucp. > > if you dont see /dev/ttyUSB* then look in the kernel logfile. > > mirek wrote: > >> hello >> >> can you give me some howto, how to create a /dev/ttyUSBx device? i am >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From netbeans at gatworks.com Thu Feb 28 05:15:55 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 28 Feb 2008 07:15:55 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C69FBF.7010504@host.sk> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> <47C5E9D9.9030004@host.sk> <47C5F6BE.8040809@gatworks.com> <47C69FBF.7010504@host.sk> Message-ID: <47C6A5FB.3060704@gatworks.com> from: http://www.linux-usb.org/USB-guide/x356.html insmod usb-serial.o vendor=0xVVVV product=0xPPPP, where you need to change the VVVV and PPPP to match your device. for the VENDOR id and PRODUCT id, u probably would have to look in /proc/bus/usb mirek wrote: > ok - so - when i try to plug my device (combination of ds2490 and ds9490 > and ds1408 i think (temperature sensor)), this is, what happend: > > - the module ds2490 is loaded. if i want to use digitemp, i need to > unload this module, because it doesnt work with > - anyway - no /dev/ttyUSB* created > - after loading ds2490 module to the kernel, this is the dmesg result: > [ 1261.628000] usb 4-1: USB disconnect, address 3 > [ 1264.464000] usb 4-1: new full speed USB device using uhci_hcd and > address 4 > [ 1264.628000] usb 4-1: configuration #1 chosen from 1 choice > [ 1287.660000] Driver for 1-wire Dallas network protocol. > [ 1287.760000] usbcore: registered new interface driver DS9490R > - the device is loaded to the /dev/bus/usb/001/001 > > so - yes - all is done automaticaly, but not the way i need to :-( i am > using ubuntu 7.10 (the same result are with the desktop and server > edition). i would like to use 1-wire api from maxim dallas in > combination with the rxtx libraries, but cannot make it work with the > usb port :-( > > any other suggestions? i will appreciate your help... > > mirek > > gat wrote: >> its, on most unix's, created automagically. When u plug in the device, >> the kernel/usb subsystem will ( attempt to ) recognze the device and >> install the appropriate device driver. It might also install the >> usb-serial device driver also. All done automagically. U can observe the >> transaction in the kernel log file /var/log/messages. Device major and >> minor device id's are enabled for that device. >> On the user side, a program is awaken ( i dont know which ) and reads >> its config table, and creates /dev/ttyUSBx, usually owned by uucp. >> >> if you dont see /dev/ttyUSB* then look in the kernel logfile. >> >> mirek wrote: >> >>> hello >>> >>> can you give me some howto, how to create a /dev/ttyUSBx device? i am >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -- > e-mail: mirek[[at]]cnl.tuke.sk > jabber: mirek[[at]]jabbim.sk > homepage: http://www.cnl.tuke.sk/~mirek > > english: > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > slovak: > prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) > precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From pl78 at katamail.com Thu Feb 28 12:26:21 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 20:26:21 +0100 Subject: [Rxtx] IndexError: index out of range: 1 Message-ID: <47C70ADD.5000502@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080228/83786821/attachment-0009.html From pl78 at katamail.com Thu Feb 28 15:07:42 2008 From: pl78 at katamail.com (pl) Date: Thu, 28 Feb 2008 23:07:42 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier Message-ID: <47C730AE.1070101@katamail.com> RXTX with jython return this error..... Jython 2.2.1 on java1.6.0_03 >>> import serialjava Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Traceback (innermost last): File "", line 1, in ? File "/home/maverick/Progetto/serialjava.py", line 10, in ? ImportError: cannot import name CommPortIdentifier >>> thanks PL From pl78 at katamail.com Fri Feb 29 02:09:11 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:09:11 +0100 Subject: [Rxtx] RXTX and jython Message-ID: <47C7CBB7.1030600@katamail.com> This application run very well from Eclipse/linux, but in windows return this error: C:\condivise\Lib>java org.python.util.jython test.py None Testing port 1 Test RTS/CTS ... Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ====================================================================== ERROR: Test RTS/CTS ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\condivise\Lib\unittest.py", line 204, in __call__ File "test.py", line 120, in setUp File "C:\condivise\Lib\serial\serialjava.py", line 47, in __init__ File "C:\condivise\Lib\serial\serialjava.py", line 21, in device AttributeError: 'module' object has no attribute 'CommPortIdentifier' From michael.erskine at ketech.com Fri Feb 29 02:21:41 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 29 Feb 2008 09:21:41 +0000 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C730AE.1070101@katamail.com> References: <47C730AE.1070101@katamail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Pl wrote... > RXTX with jython return this error..... > Jython 2.2.1 on java1.6.0_03 > >>> import serialjava > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Traceback (innermost last): > File "", line 1, in ? > File "/home/maverick/Progetto/serialjava.py", line 10, in ? > ImportError: cannot import name CommPortIdentifier So, we see that the native library starts to load. I know practically nothing about Jython. Do you have rxtx working under Java? Regards, Michael Erskine. From pl78 at katamail.com Fri Feb 29 02:57:48 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 10:57:48 +0100 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> Message-ID: <47C7D71C.50608@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/1bc77bef/attachment-0009.html From Martin.Oberhuber at windriver.com Fri Feb 29 06:03:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 29 Feb 2008 14:03:52 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804A8217A@ism-mail03.corp.ad.wrs.com> > - MinGW. I was able to install MSYS without trouble a couple of years > ago, but I can't find that straightforward installer anymore. Since I know you use Eclipse as well, the simplest installer that includes MSYS is Wascana -- complete CDT for Windows environment including MSYS: http://sourceforge.net/projects/wascana/ You might also like to hear that rxtx-2.1-7r2 (plus some patches) is available as an Eclipse plugin that doesn't require patching the JVM. There is an Eclipse Update Site as well as a Download area - see this for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175336#c5 A list of patches compared to 2.1-7r2 is here: http://rxtx.qbang.org/eclipse/downloads/README-I20071016-1945.html Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From ajmas at sympatico.ca Fri Feb 29 06:50:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Feb 2008 08:50:09 -0500 Subject: [Rxtx] ImportError: cannot import name CommPortIdentifier In-Reply-To: <47C7D71C.50608@katamail.com> References: <47C730AE.1070101@katamail.com> <06BA3262D918014F9183B66425D5A8D425240DE578@no-sv-03.ketech.local> <47C7D71C.50608@katamail.com> Message-ID: <3B0E164E-4EB4-4C0B-B35F-FBEA27E38659@sympatico.ca> Hi, I don't know much about jython, but normally I would put all the application components together, instead of spreading them across the system. For example: My App Folder/ bin/ lib/ resources/ At this point the launch script would point both the native library path and the classpath to the lib folder. This helps keeps things organised and together. BTW on some platforms, such as MacOS X, while using a launch script is tollerable, it is recommended to bundle everything together as an application bundle: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html Another approach of distributing you application is as a WebStart, though this may not necessarily fit your distribution model. Andre On 29-Feb-08, at 04:57 , pl wrote: > thanks Michael, > > On Windows > 1) i put RXTX.comm in ..java/lib/ext > 2) i put rxtxserial.dll in ..java/lib > On Linux > 1) RXTXcomm.jar in /jre/lib/ext (under java) > 2) librxtxSerial.so in /jre/lib/[machine type] > > Now my application work; > but the problem remains: how do the application porting from linux > to Windows/MAC/Solaris without manually copy the dll and rxtx.comm ? > > My application will be distributed with jar > > thanks > > > > > Michael Erskine wrote: >> >> Pl wrote... >> >>> RXTX with jython return this error..... >>> Jython 2.2.1 on java1.6.0_03 >>> >>> import serialjava >>> Experimental: JNI_OnLoad called. >>> Stable Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7 >>> Java lib Version = RXTX-2.1-7 >>> Traceback (innermost last): >>> File "", line 1, in ? >>> File "/home/maverick/Progetto/serialjava.py", line 10, in ? >>> ImportError: cannot import name CommPortIdentifier >>> >> So, we see that the native library starts to load. I know >> practically nothing about Jython. Do you have rxtx working under >> Java? >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From benedums at comcast.net Fri Feb 29 11:23:27 2008 From: benedums at comcast.net (Sailin) Date: Fri, 29 Feb 2008 12:23:27 -0600 Subject: [Rxtx] Serial Comm on FTDI device Message-ID: <000401c87b00$2e4290f0$8ac7b2d0$@net> I'm trying to communicate with a FTDI USB Serial Port device in Windows. I'm able to connect to the port & send data but I get no response from notifyOnDataAvailable or with a thread that monitors the data available. I know the RXTX library loads correctly because I get: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 I know the device is working correctly because I have a win32 app that is able to communicate with it. I'm not an expert with how FTDI chips work but I'm sending a byte[] to the device to "getPowerMode", I'm about 75% confidant that the data array is correct. Is there something special I need to do to configure RXTX to work with FTDI devices? Has anyone had a similar problem or have any suggestions on what may be wrong? Thanks, Sailin Benedum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080229/950c7cd0/attachment-0008.html From tod at todbot.com Fri Feb 29 12:23:00 2008 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 29 Feb 2008 11:23:00 -0800 Subject: [Rxtx] Anyone using USB CDC ACM devices with RXTX? Message-ID: Hi, I'm working on a project using Atmel's AT90USB line of microcontrollers. One of their demo firmwares is a CDC device, meant to act as a USB-to-serial converter. With this firmware installed on the chip, it appears as a /dev/tty.usbmodem on Mac OS X and I can open and use it fine with minicom, zterm, screen, my own C code, etc. However, when I connect to it with Java code that uses RXTX, the code will never exit unless I control-C it. It seems "port.close()" never returns. Sometimes having the CDC device send a lot of data will let port.close() return, sometimes not. The Java code is a single page of bog-standard javacomm stuff and implements SerialEventListener to echo back data received. Seems like some sort of weird deadlock. This is on Mac OS X 10.5.2, using either the download version of RXTX-2.1.7, the slightly-improved version of RXTX-2.1.7 that ships with Arduino, and the rxtx-devel trunk from CVS. (btw, thank you for updating the wiki with more accurate instructions than the website for building a usable RXTX) So my questions are: Anyone have luck using USB CDC devices with RXTX? Or is there any known oddness with RXTX wrt USB CDC that I could change in the firmware to make this issue not happen? Thanks, -=tod --- Tod E. kurt tod at todbot.com From pl78 at katamail.com Fri Feb 29 14:33:47 2008 From: pl78 at katamail.com (pl) Date: Fri, 29 Feb 2008 22:33:47 +0100 Subject: [Rxtx] rxtx porting Message-ID: <47C87A3B.3030405@katamail.com> How can i do the java application porting from linux to Windows/MAC/Solaris without copy the dll and rxtx.comm manually in java lib path of the target system ? My application use rxtx.comm for serial communication and will be distributed by jar archive. Thanks PL From howard at qtutrains.com Fri Feb 29 22:24:41 2008 From: howard at qtutrains.com (Howard) Date: Sat, 1 Mar 2008 18:24:41 +1300 Subject: [Rxtx] NoClassDefFoundError: CommPortIdentifier Message-ID: I have been using javax.comm for many years on Windows. I have RxTx 2.1 working on Windows, Linux and Mac OS X I need V2.0 (javax.comm namespace) because I have users with comm.jar So I downloaded rxtx-2.0-7pre1 but the pre-built jnilib was for PowerPC, I have Intel Start up XCode and got compile error (type redefined), changed the .h to match the .c and compiled again. Copy jnilib to /Library/Java/ Extensions My app loads comm.jar which reads javax.comm.properties, then librxtxSerial.jnilib THEN I get: Caught java.lang.NoClassDefFoundError: javax.comm/CommPortIdentifier while loading driver gnu.io.RXTXCommDriver I am puzzled by the '/' instead of '.' Does anyone have pre-built files for INTEL MAC OS X ? I cannot find any on the www. Thanks, Howard Amos From rite2sagun at gmail.com Sat Feb 2 01:44:29 2008 From: rite2sagun at gmail.com (Sagun) Date: Sat, 2 Feb 2008 09:44:29 +0100 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> Message-ID: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> I having using rxtx library to read com ports in desktop application in windows. it works fine. but when i tried using it in a java applet(signed applet) it hangs where enumeration of the ports takes place with following exception. ============== java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(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) Caused by: java.security.AccessControlException: access denied ( java.lang.RuntimePermission loadLibrary.rxtxSerial) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkLink(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) ... 23 more ============= Do you know a working a solution for rxtx in applet. I would appreciate it if you could give any kind of resource. thanking you in advance. -- Warm Regards, S Dhakhwa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080202/4768a567/attachment-0037.html From netbeans at gatworks.com Sat Feb 2 02:12:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 02 Feb 2008 04:12:49 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <47A43411.5080804@gatworks.com> Its an applet security issue: > Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown Source) u have to get the owner of the browser/account to give you specific permission to load up the ( potentially ) virus/malware software. I dont know how to setup the security manager for RXTX. Sagun wrote: > I having using rxtx library to read com ports in desktop application in > windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > From ajmas at sympatico.ca Sat Feb 2 06:40:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 2 Feb 2008 08:40:07 -0500 Subject: [Rxtx] rxtx in applet In-Reply-To: <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: I would suggest using webstart, rather than an applet. I don't believe an applet can ask for the same security permissions and a webstart application. Do note that when using webstart to make sure you sign your jars. A self-signed signature will do. Below is one I did myself. Note that I separated the rxtx stuff into a separate JNLP to make it easier to reuse. http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Andre On 2-Feb-08, at 03:44 , Sagun wrote: > I having using rxtx library to read com ports in desktop application > in windows. it works fine. but when i tried using it in a java > applet(signed applet) it hangs where enumeration of the ports takes > place with following exception. > > ============== > java.lang.ExceptionInInitializerError thrown while loading > gnu.io.RXTXCommDriver > Exception in thread "AWT-EventQueue-2" > java.lang.ExceptionInInitializerError > at com2web.DeviceTabPane.readButtonClicked(DeviceTabPane.java:97) > at com2web.DeviceTabPane.access$000(DeviceTabPane.java:31) > at com2web.DeviceTabPane$1.mouseClicked(DeviceTabPane.java:71) > at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown > Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(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) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission loadLibrary.rxtxSerial) > at java.security.AccessControlContext.checkPermission(Unknown > Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkLink(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > ... 23 more > > ============= > > Do you know a working a solution for rxtx in applet. I would > appreciate it if you could give any kind of resource. > thanking you in advance. > > > > -- > Warm Regards, > S Dhakhwa > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sun Feb 3 11:51:44 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 3 Feb 2008 13:51:44 -0500 Subject: [Rxtx] Wiki spamming Message-ID: <20D97A3A-8B94-4FC1-AEE0-3B8D49382A47@sympatico.ca> Hi, The Wiki has been hit by spammers, yet again. Pages which I cleaned up less than two days ago were already spammed again! I have deleted pages that had no previous content except for spam, and added supplementary protection to pages that had been spammed again almost immediately. I have made an attempt to block the user accounts causing the damage. If in doing so I have accidently blocked legitimate access to anything, please let me know. At the moment I am acting more on damage control, and if we can find a better long term solution, all the better. Andre From beat.arnet at gmail.com Sun Feb 3 15:22:53 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 03 Feb 2008 17:22:53 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() In-Reply-To: References: <47717688.20002@gmail.com> <4772B0E6.2050803@gmail.com> Message-ID: <47A63EBD.5020005@gmail.com> I am happy to confirm that Trent was right with his suspicion (see below). Once I changed the line to /* no DTR control in termios? */ dcb.fDtrControl = DTR_CONTROL_DISABLE; the DTR ended up being unaffected by a setSerialPortParams() call, i.e. problem solved! The modified source-code is available on my web-site along with quick instructions on how to compile it on a Windows machine: http://www.codeskin.com/c2oooProg_faq.html#rxtx Cheers, Beat Trent Jarvi wrote: > > staticSet* would be passed the filename ("COM1" for instance) even > after opening the port. There may be another subtle bug there. As I > mentioned that code was never tested. It looks like the problem with > DTR asserting is in termios.c:tcsetattr() > > /* no DTR control in termios? */ > dcb.fDtrControl = DTR_CONTROL_ENABLE; > > This function is called towards the end of setSerialPortParams in > SerialImp.c. The static version will do the same. The solution may > be to just remove the code that tries to fiddle with DTR while trying > to emulate the termios struct. > > One way to test the theory would be to try it out on a > Linux/Mac/Solaris box since they don't go into termios.c. Presumably > they would work. > > Taking out that DTR code might introduce an incompatability for > existing code since some devices will not communicate until it is > asserted. Not that we would not do it, but it is not a change without > risk. > > On Wed, 26 Dec 2007, Beat Arnet wrote: > >> Hello Trent, >> >> Thank you so much for the quick response! >> >> I have tried your suggestion, by calling staticSetDTR("COM1", false) >> before opening the port. >> Afterwards, I open the serial port and setDTR(true) followed by >> setDTR(false), which resets the target that I am attempting to >> program over RS-232. Then, I download the first portion of the code >> at a low transmission rate. After that, I need to reconfigure the >> port to run at a faster rate, for which I call setSerialPortParams() >> - unfortunately, even with the initial staticSetDTR call that you >> recommended, the setSerialPortParams() call still sets DTR=true, >> resulting in an unwanted reset of the target. Also, any subsequent >> call to staticSetDTR (after the port has been opened) results in the >> following error: >> >> Error 0x2 at >> /home/bob/foo/tar/rxtx-2.1-7/build/../src/termios.c(860): The system >> cannot find the file specified. >> >> Am I using the staticSetDTR function as you intended and/or is there >> anything else that I should try? >> >> Regards, >> Beat >> >> Trent Jarvi wrote: >>> On Tue, 25 Dec 2007, Beat Arnet wrote: >>> >>>> Hello all, >>>> It looks as if setSerialPortParams() is also setting DTR=true. In my >>>> application this is undesirable - is there anything that can be >>>> done to >>>> keep DTR==false while I reconfigure (the speed of) the port? I looked >>>> through the JAVA portion of gnu.io and could not find a single place >>>> where setDTR(true)is executed. I therefore suspect that DTR is >>>> affected >>>> by some lower-level (native) code.... >>>> >>>> Thanks for your help, >>>> Beat >>>> >>> >>> The following in RXTXPort.java may help you. I was putting this code >>> in several years ago and never really verified it. The idea is the >>> call will open the port (DTR) will be asserted but after that, the >>> port is 'preopened' meaning your later call to open with not assert >>> the pin. >>> >>> NOTE: This is not part of CommAPI. I think it will work on the OS's >>> RXTX supports though. >>> >>> >>> /** >>> * Extension to CommAPI >>> * This is an extension to CommAPI. It may not be supported on >>> * all operating systems. >>> * >>> * Open the port and set DTR. remove lockfile and do not close >>> * This is so some software can appear to set the DTR before 'opening' >>> * the port a second time later on. >>> * >>> * @return true on success >>> * @throws UnsupportedCommOperationException; >>> * >>> */ >>> >>> public static boolean staticSetDTR( String port, boolean flag ) >>> throws UnsupportedCommOperationException >>> { >>> if ( debug ) >>> z.reportln( "RXTXPort:staticSetDTR( " + port + >>> " " + flag ); >>> return( nativeStaticSetDTR( port, flag ) ); >>> } >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> > From michael.erskine at ketech.com Mon Feb 4 02:04:26 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 4 Feb 2008 09:04:26 +0000 Subject: [Rxtx] rxtx in applet In-Reply-To: References: <958dc0190802010025q650e450fwa06a04d1f8988b3e@mail.gmail.com> <958dc0190802020044y1fa76205la08ca1fb837c4a83@mail.gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240706E1@no-sv-03.ketech.local> Andre-John Mas wrote > I would suggest using webstart, rather than an applet. I don't believe > an applet can ask for the same security permissions and a webstart > application. Do note that when using webstart to make sure you sign > your jars. A self-signed signature will do. > Below is one I did myself. Note that I separated the rxtx stuff into a > separate JNLP to make it easier to reuse. > > http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp Whilst webstart is preferred nowadays, a signed applet should be able to do anything a webstart app can do. Regards, Michael Erskine. From james.i.brannan at lmco.com Mon Feb 4 14:49:10 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:49:10 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I'm stabbing in the dark here.... You don't suppose some issue like this could be effecting my application? I.E. I monitor for CTS and DSR pulses. I set DTR to false so it acts as a negative for the circuit I create. I.E. psuedocode (in this order) set DTR to FALSE set RTS to TRUE where the bicycle magnet is the switch allowing power to flow from RTS to CTS and DSR, and DTR functions as the negative. I know that a bad DTR connection does immitate the behavior I'm seeing running RXTX on Windows. Don't get the behavior on Linux. Sorry havent been on this issue more, but been working on about a million Mac display issues with AWT. Then its back to the RXTX issue. btw (this is an html conversion of a word document I threw up to try getting alpha testers on another list I belong to) http://home.earthlink.net/~jamesbrannan/IntervalTrack.htm James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/c9944cc9/attachment-0034.html From james.i.brannan at lmco.com Mon Feb 4 14:52:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Mon, 04 Feb 2008 16:52:11 -0500 Subject: [Rxtx] Maintaining DTR=false during setSerialPortParams() Message-ID: I should mention this document was before deciding upon RXTX....obviously RXTX would have been mentioned alongside JLGui and Mplayer..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080204/7e9c97a0/attachment-0034.html From dfernandez at edpingenieria.com Tue Feb 5 02:46:17 2008 From: dfernandez at edpingenieria.com (=?ISO-8859-1?Q?Daniel_Fern=E1ndez?=) Date: Tue, 05 Feb 2008 10:46:17 +0100 Subject: [Rxtx] Update on issue "Error 0x5..." Message-ID: <47A83069.5080000@edpingenieria.com> Hi all, I'm actually using rxtx 2.1.7-r2, and I have found a problem that is described in this thread (http://mailman.qbang.org/pipermail/rxtx/2007-February/1913974.html). I haven't found any newer reference to this issue, so I would appreciate if somebody could provide any update on it. Best regards, Daniel From james.i.brannan at lmco.com Thu Feb 7 08:25:09 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 07 Feb 2008 10:25:09 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed Message-ID: Okay, I'm a higher level programmer, and have little experience with hardware interfacing. Need some advice. In a nutshell, followed some online example on how to turn my bicycle computer's cadence and speed magnets into sensors for serial port. basically wire from RTS to CTS and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and then count length of time between CTS signals - when the switch switches - I count it and calculate speed. Same for DTR and cadence. (Oh, I do average over a second and I only count + to - not + to - to +). Here's a diagram of where I got the hardware idea from an older similar program: http://users.pandora.be/jim.de.sitter/html/spinner.html Here's the deal. I'm finding variability in how well it works. RXTX performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port binaries perform wonderfully on Windows (both with dongle and without). I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it performed mediocre (accurate enough that I don't suspect a RXTX bug as with Windows - but bad enough that I suspect the Dongle hardware or driver - or could be threading in Java). Here's the advice, seeked. Am I asking too much to expect counting CTS and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a dongle? My goal was to offer multimedia software for folks as nagware for a dirt cheap price when/or-if they decided to buy it. I now have two options, one: hack the serial communication coming from a device that takes the data and then translates it into a more-typical serial port communication (i.e. it already does the signal counting and then sends the numbers to the serial port every second - since numbers coming from the device are already calculated averages - inacuracy is okay if I drop a few serial port signals)....problem with this approach is it will require users to purchase a $100 sensor set. The other option is to try going to the POSIX level and testing that in a simple program and see if that works in Mac. If that works then use it and/or try to work on RXTX's lower level code..... Question is this, am I trying to do something that just isnt meant to be done? It seems to me that asking a computer to calculate events that occur a few times a second is no big deal. But my work experience is basically programming to Weblogic, and/or Apache Aps..so I realize my limitations. Basically, those of you with more experience, I'm asking for your opinion/advice on this technique given your experience with serial ports. Thanks, James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/72f8673f/attachment-0031.html From jredman at ergotech.com Thu Feb 7 10:02:27 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 07 Feb 2008 10:02:27 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: <47AB39A3.5050809@ergotech.com> James, I don't have much experience monitoring control line switches, so greater minds may wish to contribute.. If you're expecting this to be a money making venture, I think that you've already isolated enough problems that you might want to rethink. You will spend your whole life supporting people who don't know how to install USB serial ports and/or the associated hardware. Don't forget that on Windows, just because yesterday it was COM4: doesn't mean that it is today. That said, I would expect that this is do-able. We use RXTX on Linux only and use JavaCOMM on Windows (can I admit that on this list?). You should be able to catch pulses up to about 10Hzs relatively easily on any modern PC. We've played with control line switching on 485 interfaces and succeeded in switching them down at the low ms range (usually - it's not reliable at that level). So if you're doing this for fun, I would urge you to keep at it, especially if you have the time/energy/inclination to dig deep into RXTX code. If RXTX is working correctly, you may gain insight into USB dongles that would also be valuable (to you and others). Jim PS I think that De Sitter (the original link) is a great name for a bicyclist. Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don?t suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)?.problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code?.. > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial ports. > > Thanks, > James A. Brannan > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tjarvi at qbang.org Thu Feb 7 21:14:16 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Feb 2008 21:14:16 -0700 (MST) Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: On Thu, 7 Feb 2008, Brannan, James I (N-Fenestra) wrote: > Okay, I'm a higher level programmer, and have little experience with > hardware interfacing. Need some advice. In a nutshell, followed some > online example on how to turn my bicycle computer's cadence and speed > magnets into sensors for serial port. basically wire from RTS to CTS > and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), and > then count length of time between CTS signals - when the switch switches > - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > average over a second and I only count + to - not + to - to +). > > Here's a diagram of where I got the hardware idea from an older similar > program: http://users.pandora.be/jim.de.sitter/html/spinner.html > > Here's the deal. I'm finding variability in how well it works. RXTX > performs wonderfully on Ubuntu, woefull on Windows. Java's Serial Port > binaries perform wonderfully on Windows (both with dongle and without). > I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it > performed mediocre (accurate enough that I don't suspect a RXTX bug as > with Windows - but bad enough that I suspect the Dongle hardware or > driver - or could be threading in Java). > > Here's the advice, seeked. Am I asking too much to expect counting CTS > and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without a > dongle? My goal was to offer multimedia software for folks as nagware > for a dirt cheap price when/or-if they decided to buy it. I now have > two options, one: hack the serial communication coming from a device > that takes the data and then translates it into a more-typical serial > port communication (i.e. it already does the signal counting and then > sends the numbers to the serial port every second - since numbers coming > from the device are already calculated averages - inacuracy is okay if I > drop a few serial port signals)....problem with this approach is it will > require users to purchase a $100 sensor set. The other option is to try > going to the POSIX level and testing that in a simple program and see if > that works in Mac. If that works then use it and/or try to work on > RXTX's lower level code..... > > Question is this, am I trying to do something that just isnt meant to be > done? It seems to me that asking a computer to calculate events that > occur a few times a second is no big deal. But my work experience is > basically programming to Weblogic, and/or Apache Aps..so I realize my > limitations. > > Basically, those of you with more experience, I'm asking for your > opinion/advice on this technique given your experience with serial > ports. > As I mentioned on the list before, I tried flicking a DTR by hand and was able to observe the events faster than you did on the bike. So I am not sure what is going on at this point. I'd like to get a function generator working with higher voltage swings so I can investigate further but there are many things I'd like to do. A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From jason.henriksen at gmail.com Thu Feb 7 23:13:12 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 22:13:12 -0800 Subject: [Rxtx] osx fixperm.sh problem Message-ID: <44806a570802072213l537abbdbja4b3d0b713446cd@mail.gmail.com> Hi All, I'm sure you've already heard, but fixperm.sh for OS X is broken. It's a trivial fix, just remove the newline after the line ending with $curruser > That will give you a line that looks like: if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] For any unix noobs struggling with this, remember that you must call: chmod u+x ./fixperm.sh before you try to run the script. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/f0ae8efe/attachment-0031.html From miguel.cabanas at gmail.com Fri Feb 8 00:10:38 2008 From: miguel.cabanas at gmail.com (Miguel Cabanas) Date: Fri, 8 Feb 2008 08:10:38 +0100 Subject: [Rxtx] installing rxtx in ubuntu Message-ID: Hello, I m trying to install rxtx libraries in my ubuntu laptop to use them using gpstools but an error occurs and the driver is not properly charged. could anybody give me a HOW TO ? I followed the guidelines http://www.rxtx.org/ but they dont seem really clear for me ... are the libserial.so necessary? thank you in advance, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080208/1d12245d/attachment-0031.html From jason.henriksen at gmail.com Fri Feb 8 00:41:33 2008 From: jason.henriksen at gmail.com (Jason Henriksen) Date: Thu, 7 Feb 2008 23:41:33 -0800 Subject: [Rxtx] ARG. OS X: Isn't really available. Message-ID: <44806a570802072341v5ae320bfy6f116a4364af8de5@mail.gmail.com> So according to this page: http://rxtx.qbang.org/wiki/index.php/FAQ#On_MacOS_X_I_get_a_.27PortInUseException.27.2C_even_though_it_isn.27t.3F OS X, really needs to be running 2.1-8. I need to know if this is really truly stable, or if it's just kind of working. I'm trying to test something on OS X. Could I get a statement of its stability? Is there any chance of a binary build coming available? Thanks, Jason Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080207/b7b60ff7/attachment-0031.html From james.i.brannan at lmco.com Fri Feb 8 07:44:49 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:44:49 -0500 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: Message-ID: Given it more thought, relying on any DAQ device, kind of blows this product's niche. I need to test the Mac OS X code from the commandline using the same program I posted here last month. It just dawned on me I was executing my GUI program by running it in NetBeans on the Mac (and we all know how sleek and fast Netbeans is ...). However, the behavior on Mac that I noticed last night was that up to 12kph the kph was spot on. As I increased in speed it started fluctuating between 12kph and the actual speed. So somewhere between the dongle and my code stuff is getting dropped as the revolutions increase....but if the code is the same between Linux and Mac OS X, then that means its in the Java or in the user space timing issues (which I'll have to research)....cause the Linux version was dead on when I tested it. I'm going to try a simple C program, see how accurate that is. If that's not accurate, then its rebirthed as a Multimedia Stopwatch ;-) As for this being a hobby....I'm thinking this baby could easily sell 200 or so copies of this if I get the serial IO working and *easy* to install. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Thursday, February 07, 2008 11:14 PM To: Brannan, James I (N-Fenestra) Cc: rxtx at qbang.org A msec is a long time for the USB dongles if they do support DTR in the kernel driver. More likely, you will run into user space timing issues. This may be what you are seeing on Mac OS X. There is the possibility that rxtx or the dongles are inadvertantly swallowing some of the events on win32. I didn't observe that though. The Mac OS X code in rxtx is almost identical to Linux for your purposes. I doubt there is much that can be done there. $100 is fairly expensive for other alternatives. There are USB DAQ devices with multiple inputs available for < $50. There are other reasons to get your case working. Parallel ports are becomming less popular at a faster rate than serial ports. The typical hobby examples like yours used parallel ports. School projects come to mind. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Fri Feb 8 07:56:21 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 08 Feb 2008 09:56:21 -0500 Subject: [Rxtx] ARG. OS X: Isn't really available. In-Reply-To: References: Message-ID: You have to create the appropriate locks folder and assign permissions. look for the thread RXTX, MacOS X and /var/lock back in October for more discussion....but here's the commands to set your machine up. sudo mkdir /var/lock sudo chmod 1777 /var/lock and it works. Not a production solution, but it will get you going. Hopefully the release doing away with locks will be out soon.... James A. Brannan From jredman at ergotech.com Fri Feb 8 11:10:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Fri, 08 Feb 2008 11:10:57 -0700 Subject: [Rxtx] OT - (Long) Serial Port Advice Needed In-Reply-To: References: <47AB39A3.5050809@ergotech.com> Message-ID: <47AC9B31.8080808@ergotech.com> James, Rather than create a whole new program, why don't you try to use the lower levels of RXTX. If there's a real problem in the code, I suspect that you'll get help here to fix it. Start with the C code, short circuit the Java interface and see if it's picking up the events. You'll get a clear indication of where the problem lies, you'll help your fellow RXTX users, and I think they'll help you. Almost unrelated and nothing to do with RXTX. If you hook the bike computer into a joystick port and have the user pedal the bike to move in a game I'd buy it for the kids. There are treadmill versions of this, but treadmills are expensive, most kids have a bike. There are also, of course, larger commercial versions, but the low cost, home version would be a good thing. I could just imagine Mario Cart where you actually have to pedal to win. Steering might be a problem, but then (for me) it always is in Mario Cart. Jim PS If you do want to hook up to a joystick port, take a look at MAME and the arcade machines built around it. All the parts are there and inexpensive. Brannan, James I (N-Fenestra) wrote: > Thanks for the response. Believe me, the support aspect has crossed my > mind...... > > As its just counting pulses, I'm going to try writing a simple c > commandline program on my mac today, see how accurate it is and then go > from there...maybe have it do all the calculating then have java call it > every second or so for the calculated totals. > > The key to this product is cheap hardware, as if folks have money they > are going to buy the much more full-featured daq-based options like > www.computrainer.com or www.tacx.com > > I cant see something that rotates less then 15 times per second being > all that taxing on the processor, but I obviously don't know much about > lower level programming (to me C and Posix is low level...).... > > My hunch is that the native code layer going to rxtx java api level, > going to my program's calculation subroutine, is just too slow....so if > I can put all that in a c routine.... > > I.E. > > spawn java thread that invokes c native code > c blocks for signals and c does the speed & cadence calculation > every second the java thread polls for the current speed and cadence > > If that doesn't work, then to hell with it, it's a multimedia stopwatch > for working out (which suprisingly nobody has thought of yet.....) > > If nothing else, this project switched me to being a Mac user, and > ingrained the importance of going back to night school to take some UNIX > systems programming classes (that's the cool part about the MAC, there's > knowledge crossover). > > Thanks for the response, > James A. Brannan > > -----Original Message----- > From: Jim Redman [mailto:jredman at ergotech.com] > Sent: Thursday, February 07, 2008 12:02 PM > To: Brannan, James I (N-Fenestra) > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] OT - (Long) Serial Port Advice Needed > > James, > > I don't have much experience monitoring control line switches, so > greater minds may wish to contribute.. > > If you're expecting this to be a money making venture, I think that > you've already isolated enough problems that you might want to rethink. > You will spend your whole life supporting people who don't know how to > install USB serial ports and/or the associated hardware. Don't forget > that on Windows, just because yesterday it was COM4: doesn't mean that > it is today. > > That said, I would expect that this is do-able. We use RXTX on Linux > only and use JavaCOMM on Windows (can I admit that on this list?). You > should be able to catch pulses up to about 10Hzs relatively easily on > any modern PC. We've played with control line switching on 485 > interfaces and succeeded in switching them down at the low ms range > (usually - it's not reliable at that level). > > So if you're doing this for fun, I would urge you to keep at it, > especially if you have the time/energy/inclination to dig deep into RXTX > code. If RXTX is working correctly, you may gain insight into USB > dongles that would also be valuable (to you and others). > > Jim > > PS I think that De Sitter (the original link) is a great name for a > bicyclist. > > > Brannan, James I (N-Fenestra) wrote: >> Okay, I'm a higher level programmer, and have little experience with >> hardware interfacing. Need some advice. In a nutshell, followed some > >> online example on how to turn my bicycle computer's cadence and speed >> magnets into sensors for serial port. basically wire from RTS to CTS >> and DTR, and ground at DSR. Set RTS to True (+), DSR to false (-), > and >> then count length of time between CTS signals - when the switch > switches >> - I count it and calculate speed. Same for DTR and cadence. (Oh, I do > >> average over a second and I only count + to - not + to - to +). >> >> Here's a diagram of where I got the hardware idea from an older > similar >> program: _http://users.pandora.be/jim.de.sitter/html/spinner.html_ >> >> Here's the deal. I'm finding variability in how well it works. RXTX >> performs wonderfully on Ubuntu, woefull on Windows. Java's Serial > Port >> binaries perform wonderfully on Windows (both with dongle and > without). >> I finally tested RXtX on OS -X 10.5 on a 2gig 2mgz dual laptop and it >> performed mediocre (accurate enough that I don't suspect a RXTX bug as > >> with Windows - but bad enough that I suspect the Dongle hardware or >> driver - or could be threading in Java). >> >> Here's the advice, seeked. Am I asking too much to expect counting > CTS >> and DSR to be accurate on Windows, OS-X, and Ubuntu - with and without > a >> dongle? My goal was to offer multimedia software for folks as nagware > >> for a dirt cheap price when/or-if they decided to buy it. I now have >> two options, one: hack the serial communication coming from a device >> that takes the data and then translates it into a more-typical serial >> port communication (i.e. it already does the signal counting and then >> sends the numbers to the serial port every second - since numbers > coming >> from the device are already calculated averages - inacuracy is okay if > I >> drop a few serial port signals)....problem with this approach is it > will >> require users to purchase a $100 sensor set. The other option is to > try >> going to the POSIX level and testing that in a simple program and see > if >> that works in Mac. If that works then use it and/or try to work on >> RXTX's lower level code..... >> >> Question is this, am I trying to do something that just isnt meant to > be >> done? It seems to me that asking a computer to calculate events that >> occur a few times a second is no big deal. But my work experience is >> basically programming to Weblogic, and/or Apache Aps..so I realize my >> limitations. >> >> Basically, those of you with more experience, I'm asking for your >> opinion/advice on this technique given your experience with serial > ports. >> Thanks, >> James A. Brannan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 noky at nextbus.com Fri Feb 8 14:34:32 2008 From: noky at nextbus.com (Mike Charnoky) Date: Fri, 08 Feb 2008 16:34:32 -0500 Subject: [Rxtx] read() not blocking Message-ID: <47ACCAE8.3020009@nextbus.com> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the latest prebuilt binary which supports javax.comm). Turns out that read() from a serial port InputStream sometimes returns -1 when it should block instead. This is not a problem under Linux. Because of this, there is no way to do fundamental stuff like wrap the InputStream in an InputStreamReader and perform a readLine(), since an IOException gets thrown: "Underlying input stream returned zero bytes". My workaround is simply to read one byte at a time from the InputStream and ignore when -1 is returned. Seems like others have encountered this in the past: http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html I second Knute's opinion: this does seem to be a rather serious bug! Any word on a fix for this? If so, is there a binary version of the software built which contains the fix? Mike From ritchie at gmx.at Fri Feb 8 15:54:12 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Fri, 08 Feb 2008 23:54:12 +0100 Subject: [Rxtx] Serial device crashes on port scan Message-ID: <47ACDD94.6090402@gmx.at> Hi, i am using a bluetooth serial device (pico plug) to connect a serial telescope to my java software. i can access the telescope correctly with a command line tools like sjinn: ./rs232 -d /dev/rfcomm0 -b4800 --hex -p8n1 -s "\h02040300" -r3 0 10 0 as soon as i try to connect using rxtx the bluetooth device shuts down and must be restarted (power off / on). When I halt the thread, i see in the stack the method testRead() that blocks a long time. My api call causing the testRead was CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); I "suspect" that the problem is that the serial device has not set the correct properties yet (4800 baud,...) and tries to read anyway just to test the device. Does anyone know a possible cause? or even a remedy? thanks for any help! regards, Ritchie P.S. yes, i am in the uucp group and yes, the lock files work and yes, i set read and write permission for the device. From netbeans at gatworks.com Fri Feb 8 17:01:56 2008 From: netbeans at gatworks.com (U George) Date: Fri, 08 Feb 2008 19:01:56 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACDD94.6090402@gmx.at> References: <47ACDD94.6090402@gmx.at> Message-ID: <47ACED74.9010704@gatworks.com> strace -f -o logfile java ........... would give you a log of all the system calls made on your behalf. if you make your java code simple enough, you can probably catch the system call that upsets your bluetooth. > When I halt the thread, i see in the stack the method testRead() that > blocks a long time. > My api call causing the testRead was > CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); > > From ritchie at gmx.at Sat Feb 9 11:44:41 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 19:44:41 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ACED74.9010704@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> Message-ID: <47ADF499.60808@gmx.at> Hi, ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt as link) can you see something wrong? regards, Ritchie U George wrote: > strace -f -o logfile java ........... > would give you a log of all the system calls made on your behalf. > if you make your java code simple enough, you can probably catch the > system call that upsets your bluetooth. > >> When I halt the thread, i see in the stack the method testRead() that >> blocks a long time. >> My api call causing the testRead was >> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >> >> > From tjarvi at qbang.org Sat Feb 9 12:47:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 12:47:44 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47ADF499.60808@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: I've seen this type of behavior on windows with some bluetooth devices. 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 5636 write(7, " 5636\n", 11) = 11 5636 close(7) = 0 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY The port isn't opening. Perhaps the bluetooth stack wants to find an external device before returning a fd? The above is happening at the C layer. A simple C program should be able to reproduce it. This example uses differen options for open (shownabove) but should be a good starting point to reproducing the problem with a stand alone application. You may find a way to open the port that works. http://www.eng.auburn.edu/~doug/termio.html The problem I've run into on windows when dealing with devices that are slow to open is they do not hide the connect/disconnects that may happen. Or perhaps the better devices keep 'pinging' to keep the connection alive. When you are exposed to the disconnects at the C API level, your file descriptor becomes invalid and communication is not possible without closing and opening the port again. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt > as link) can you see something wrong? > > regards, > Ritchie > > U George wrote: >> strace -f -o logfile java ........... >> would give you a log of all the system calls made on your behalf. >> if you make your java code simple enough, you can probably catch the >> system call that upsets your bluetooth. >> >>> When I halt the thread, i see in the stack the method testRead() that >>> blocks a long time. >>> My api call causing the testRead was >>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>> >>> >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sat Feb 9 15:42:39 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sat, 09 Feb 2008 23:42:39 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> Message-ID: <47AE2C5F.3050904@gmx.at> Hi, the result was: # ./a.out /dev/rfcomm0 iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 and yes! the serial device went down! so the problem is reproducible. what's next? regards, Ritchie Trent Jarvi wrote: > > I've seen this type of behavior on windows with some bluetooth devices. > > 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 > 5636 write(7, " 5636\n", 11) = 11 > 5636 close(7) = 0 > 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY > > The port isn't opening. Perhaps the bluetooth stack wants to find an > external device before returning a fd? The above is happening at the C > layer. A simple C program should be able to reproduce it. > > This example uses differen options for open (shownabove) but should be > a good starting point to reproducing the problem with a stand alone > application. You may find a way to open the port that works. > > http://www.eng.auburn.edu/~doug/termio.html > > The problem I've run into on windows when dealing with devices that > are slow to open is they do not hide the connect/disconnects that may > happen. Or perhaps the better devices keep 'pinging' to keep the > connection alive. > > When you are exposed to the disconnects at the C API level, your file > descriptor becomes invalid and communication is not possible without > closing and opening the port again. > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >> as link) can you see something wrong? >> >> regards, >> Ritchie >> >> U George wrote: >>> strace -f -o logfile java ........... >>> would give you a log of all the system calls made on your behalf. >>> if you make your java code simple enough, you can probably catch the >>> system call that upsets your bluetooth. >>> >>>> When I halt the thread, i see in the stack the method testRead() that >>>> blocks a long time. >>>> My api call causing the testRead was >>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>> >>>> >>> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sat Feb 9 18:58:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Feb 2008 18:58:06 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AE2C5F.3050904@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: The port did open in your example. It is hanging in open in rxtx. After the port goes down, what happens if you run the program a second time? RXTX will open and close the port twice. The first time is to determine if there is hardware there. It simply tries a timed out read. The second time is for user IO. The simple program I pointed to does not close the port. It also uses different flags. You may replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what rxtx does. Perhaps the port going down was reproduced but I don't see how you reproduced the open hanging. You could try opening the port more than once and also see if one of the flags above causes a hang. On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > Hi, > > the result was: > > # ./a.out /dev/rfcomm0 > iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 > > and yes! the serial device went down! so the problem is reproducible. > > what's next? > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> I've seen this type of behavior on windows with some bluetooth devices. >> >> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >> 5636 write(7, " 5636\n", 11) = 11 >> 5636 close(7) = 0 >> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >> >> The port isn't opening. Perhaps the bluetooth stack wants to find an >> external device before returning a fd? The above is happening at the C >> layer. A simple C program should be able to reproduce it. >> >> This example uses differen options for open (shownabove) but should be >> a good starting point to reproducing the problem with a stand alone >> application. You may find a way to open the port that works. >> >> http://www.eng.auburn.edu/~doug/termio.html >> >> The problem I've run into on windows when dealing with devices that >> are slow to open is they do not hide the connect/disconnects that may >> happen. Or perhaps the better devices keep 'pinging' to keep the >> connection alive. >> >> When you are exposed to the disconnects at the C API level, your file >> descriptor becomes invalid and communication is not possible without >> closing and opening the port again. >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> Hi, >>> >>> ok, done, here is the logfile (http://www.upto.org/microsky/logfile.txt >>> as link) can you see something wrong? >>> >>> regards, >>> Ritchie >>> >>> U George wrote: >>>> strace -f -o logfile java ........... >>>> would give you a log of all the system calls made on your behalf. >>>> if you make your java code simple enough, you can probably catch the >>>> system call that upsets your bluetooth. >>>> >>>>> When I halt the thread, i see in the stack the method testRead() that >>>>> blocks a long time. >>>>> My api call causing the testRead was >>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From jamesbrannan at earthlink.net Sat Feb 9 21:45:04 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 9 Feb 2008 23:45:04 -0500 (GMT-05:00) Subject: [Rxtx] OT - Interesting Band-Aid to my problem..... Message-ID: <25872360.1202618704359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> pseudocode: If newtimedelta > oldtimedelta + oldtimedelete * .3 then netimedelta = oldtimedelta else if newtimedelta < oldtimedelta - oldtimedelta * .3 then netimedelta = oldtimedelta so if i miss an event, just use the last good event. I tested it for 30 minutes and it worked on my Mac... What I found interesting, was that it seemed *more* accurate and quick to reflect speed changes then my $1000 dollar PowerTap bicycle computer....I guess I could smooth out the average to be a larger sample, and go to one decimal place, to make it as "accurate" as the powertap. So Linux is impressively accurate, so I'll make a distro for Ubuntu, Mac OSX not so much but good enough, and the windows, well I'll test this bandaid, but I'm not thinking its going to work. Also not sure how well this is going to work on my 800mhz 640mg ibook.... If nothing else this has really impressed upon me the need to strengthen my C/C++ skills if I want to continue working on stuff other then cramming data into and out of a database....it's not acceptable that I'm dead in the water if the problem doesn't lie in the Java code.....I'm going to continue working to understand the RXTX code in the context of relearning c, so hopefully I'll have something to contributions soon... James A. Brannan From ritchie at gmx.at Sun Feb 10 09:45:14 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 17:45:14 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> Message-ID: <47AF2A1A.2020607@gmx.at> Hi, now i tried a lot of combinations of settings and other combinations in the test source. the crash happens if between the tcgetattr and the "close of the file-descriptor" or "exit of the program" there is no sleep, as soon as i include a sleep the test works as expected. what does this mean in relation to getting rxtx to work with my device? is there a setting to delay the close of a connection? regards, Ritchie Trent Jarvi wrote: > > The port did open in your example. It is hanging in open in rxtx. > After the port goes down, what happens if you run the program a second > time? > > RXTX will open and close the port twice. The first time is to > determine if there is hardware there. It simply tries a timed out > read. The second time is for user IO. The simple program I pointed > to does not close the port. It also uses different flags. You may > replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what > rxtx does. > > Perhaps the port going down was reproduced but I don't see how you > reproduced the open hanging. You could try opening the port more than > once and also see if one of the flags above causes a hang. > > > On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: > >> Hi, >> >> the result was: >> >> # ./a.out /dev/rfcomm0 >> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >> >> and yes! the serial device went down! so the problem is reproducible. >> >> what's next? >> >> regards, >> Ritchie >> >> >> Trent Jarvi wrote: >>> >>> I've seen this type of behavior on windows with some bluetooth devices. >>> >>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>> 5636 write(7, " 5636\n", 11) = 11 >>> 5636 close(7) = 0 >>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>> >>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>> external device before returning a fd? The above is happening at the C >>> layer. A simple C program should be able to reproduce it. >>> >>> This example uses differen options for open (shownabove) but should be >>> a good starting point to reproducing the problem with a stand alone >>> application. You may find a way to open the port that works. >>> >>> http://www.eng.auburn.edu/~doug/termio.html >>> >>> The problem I've run into on windows when dealing with devices that >>> are slow to open is they do not hide the connect/disconnects that may >>> happen. Or perhaps the better devices keep 'pinging' to keep the >>> connection alive. >>> >>> When you are exposed to the disconnects at the C API level, your file >>> descriptor becomes invalid and communication is not possible without >>> closing and opening the port again. >>> >>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>> >>>> Hi, >>>> >>>> ok, done, here is the logfile >>>> (http://www.upto.org/microsky/logfile.txt >>>> as link) can you see something wrong? >>>> >>>> regards, >>>> Ritchie >>>> >>>> U George wrote: >>>>> strace -f -o logfile java ........... >>>>> would give you a log of all the system calls made on your behalf. >>>>> if you make your java code simple enough, you can probably catch the >>>>> system call that upsets your bluetooth. >>>>> >>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>> that >>>>>> blocks a long time. >>>>>> My api call causing the testRead was >>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >> > From ritchie at gmx.at Sun Feb 10 10:15:46 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:15:46 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3142.4070902@gmx.at> just noticed that instead of a sleep also a valid send / receive sequence will work. But just a read of 0 bytes still fails. regards, Ritchie Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. > > what does this mean in relation to getting rxtx to work with my device? > is there a setting to delay the close of a connection? > > regards, > Ritchie > > Trent Jarvi wrote: > >> The port did open in your example. It is hanging in open in rxtx. >> After the port goes down, what happens if you run the program a second >> time? >> >> RXTX will open and close the port twice. The first time is to >> determine if there is hardware there. It simply tries a timed out >> read. The second time is for user IO. The simple program I pointed >> to does not close the port. It also uses different flags. You may >> replace the flag O_RDONLY with O_RDWR|O_NONBLOCK|O_NOCTTY to do what >> rxtx does. >> >> Perhaps the port going down was reproduced but I don't see how you >> reproduced the open hanging. You could try opening the port more than >> once and also see if one of the flags above causes a hang. >> >> >> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >> >> >>> Hi, >>> >>> the result was: >>> >>> # ./a.out /dev/rfcomm0 >>> iflag - 02400; oflag - 05; cflag - 06275; lflag - 0105073 >>> >>> and yes! the serial device went down! so the problem is reproducible. >>> >>> what's next? >>> >>> regards, >>> Ritchie >>> >>> >>> Trent Jarvi wrote: >>> >>>> I've seen this type of behavior on windows with some bluetooth devices. >>>> >>>> 5636 open("/var/lock/LCK..rfcomm0", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7 >>>> 5636 write(7, " 5636\n", 11) = 11 >>>> 5636 close(7) = 0 >>>> 5636 open("/dev/rfcomm0", O_RDWR|O_NONBLOCK|O_NOCTTY >>>> >>>> The port isn't opening. Perhaps the bluetooth stack wants to find an >>>> external device before returning a fd? The above is happening at the C >>>> layer. A simple C program should be able to reproduce it. >>>> >>>> This example uses differen options for open (shownabove) but should be >>>> a good starting point to reproducing the problem with a stand alone >>>> application. You may find a way to open the port that works. >>>> >>>> http://www.eng.auburn.edu/~doug/termio.html >>>> >>>> The problem I've run into on windows when dealing with devices that >>>> are slow to open is they do not hide the connect/disconnects that may >>>> happen. Or perhaps the better devices keep 'pinging' to keep the >>>> connection alive. >>>> >>>> When you are exposed to the disconnects at the C API level, your file >>>> descriptor becomes invalid and communication is not possible without >>>> closing and opening the port again. >>>> >>>> On Sat, 9 Feb 2008, Richard van Nieuwenhoven wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> ok, done, here is the logfile >>>>> (http://www.upto.org/microsky/logfile.txt >>>>> as link) can you see something wrong? >>>>> >>>>> regards, >>>>> Ritchie >>>>> >>>>> U George wrote: >>>>> >>>>>> strace -f -o logfile java ........... >>>>>> would give you a log of all the system calls made on your behalf. >>>>>> if you make your java code simple enough, you can probably catch the >>>>>> system call that upsets your bluetooth. >>>>>> >>>>>> >>>>>>> When I halt the thread, i see in the stack the method testRead() >>>>>>> that >>>>>>> blocks a long time. >>>>>>> My api call causing the testRead was >>>>>>> CommPortIdentifier.getPortIdentifier("/dev/rfcomm0"); >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> > > > From netbeans at gatworks.com Sun Feb 10 10:19:36 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 12:19:36 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF2A1A.2020607@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> Message-ID: <47AF3228.3010502@gatworks.com> Richard van Nieuwenhoven wrote: > Hi, > > now i tried a lot of combinations of settings and other combinations in > the test source. > the crash happens if between the tcgetattr and the "close of the > file-descriptor" or "exit of the program" > there is no sleep, as soon as i include a sleep the test works as expected. I'm a bit confused. are you still describing the small test program? Or are you describing rxtx? can u open(), close(), lets say 10 times in a row? can you open(), tcgetattr(), close(), 10 times in a row? In any case this issue, i think, has to be reported to the device driver maintainer for their evaluation. From ritchie at gmx.at Sun Feb 10 10:29:29 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 18:29:29 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3228.3010502@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> Message-ID: <47AF3479.2000707@gmx.at> yes, still the small test program. with the sleep or the valid read / write i can open and close the port any number of times without any troubles. but as soon as the tcgetattr and close are to fast after each other or without write/read the device crashes. now to get rxtx working, is there a possibility to insert a delay / timeout value ... regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> Hi, >> >> now i tried a lot of combinations of settings and other combinations in >> the test source. >> the crash happens if between the tcgetattr and the "close of the >> file-descriptor" or "exit of the program" >> there is no sleep, as soon as i include a sleep the test works as >> expected. > > I'm a bit confused. are you still describing the small test program? > Or are you describing rxtx? > > can u open(), close(), lets say 10 times in a row? > can you open(), tcgetattr(), close(), 10 times in a row? > > In any case this issue, i think, has to be reported to the device > driver maintainer for their evaluation. > From tjarvi at qbang.org Sun Feb 10 11:41:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 11:41:38 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF3479.2000707@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: As Uncle George says, you are best off trying to communicate the problem to the driver author clearly with as simple of an example as possible. If you can get a fix in the driver, it will help more than just rxtx using applications. While you persue the above, you may be able to avoid a quick open/close in rxtx by using a 'specified port' as documented in the INSTALL document that comes with rxtx source: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > yes, still the small test program. > > with the sleep or the valid read / write i can open and close the port > any number of times without any troubles. > but as soon as the tcgetattr and close are to fast after each other or > without write/read the device crashes. > > now to get rxtx working, is there a possibility to insert a delay / > timeout value ... > > regards, > Ritchie > > U. George wrote: >> Richard van Nieuwenhoven wrote: >>> Hi, >>> >>> now i tried a lot of combinations of settings and other combinations in >>> the test source. >>> the crash happens if between the tcgetattr and the "close of the >>> file-descriptor" or "exit of the program" >>> there is no sleep, as soon as i include a sleep the test works as >>> expected. >> >> I'm a bit confused. are you still describing the small test program? >> Or are you describing rxtx? >> >> can u open(), close(), lets say 10 times in a row? >> can you open(), tcgetattr(), close(), 10 times in a row? >> >> In any case this issue, i think, has to be reported to the device >> driver maintainer for their evaluation. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ritchie at gmx.at Sun Feb 10 13:09:27 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Sun, 10 Feb 2008 21:09:27 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> Message-ID: <47AF59F7.7070700@gmx.at> as i specified in my original post is already use this setting -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. There is no specialized device driver, it is just a standard bluetooth serial device. And the remote device itself is a "pico plug" so access there either. as soon as i use rxtx to open the port, crash, but other software tools work without problems. I need some workaround to connect. regards, Ritchie Trent Jarvi wrote: > > > As Uncle George says, you are best off trying to communicate the > problem to the driver author clearly with as simple of an example as > possible. If you can get a fix in the driver, it will help more than > just rxtx using applications. > > While you persue the above, you may be able to avoid a quick > open/close in rxtx by using a 'specified port' as documented in the > INSTALL document that comes with rxtx source: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL > > Q. How does rxtx detect ports? Can I override it? > > rxtx tries to detect ports on by scanning /dev for files matching any > of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. > Any ones that exist, are supposed to be good for the current operating > system, and that can be read and written are offered back from > CommPortIdentifier.getPortIdentifiers(), and only these can be used as > ports. > > If you wish, you can set the system properties gnu.io.rxtx.SerialPorts > and gnu.io.rxtx.ParallelPorts. If either of these is set, then no > scanning will be carried out and only the specified ports will be > available. You can use this to make one platform look like another, > to restrict Java access to ports, or possibly for other reasons. For > example > > java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp > > will look kind of like Solaris, if you have created the appropriate > device nodes. > > A note on Linux port enumeration. We have set most ports aside. Once > the > number of possible devices started getting into the thousands, > checking them > all made little sense. Look in RXTXCommDriver.java and search for Linux. > > You will see that only /dev/ttyS* is searched but the possible > addition ports > that can be used are listed under it. Just copy the few you need. > > > > > On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > >> yes, still the small test program. >> >> with the sleep or the valid read / write i can open and close the port >> any number of times without any troubles. >> but as soon as the tcgetattr and close are to fast after each other or >> without write/read the device crashes. >> >> now to get rxtx working, is there a possibility to insert a delay / >> timeout value ... >> >> regards, >> Ritchie >> >> U. George wrote: >>> Richard van Nieuwenhoven wrote: >>>> Hi, >>>> >>>> now i tried a lot of combinations of settings and other >>>> combinations in >>>> the test source. >>>> the crash happens if between the tcgetattr and the "close of the >>>> file-descriptor" or "exit of the program" >>>> there is no sleep, as soon as i include a sleep the test works as >>>> expected. >>> >>> I'm a bit confused. are you still describing the small test program? >>> Or are you describing rxtx? >>> >>> can u open(), close(), lets say 10 times in a row? >>> can you open(), tcgetattr(), close(), 10 times in a row? >>> >>> In any case this issue, i think, has to be reported to the device >>> driver maintainer for their evaluation. >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tjarvi at qbang.org Sun Feb 10 14:02:22 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 14:02:22 -0700 (MST) Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: Bluetooth as a tty is specialized in many ways even if it is a shared driver. You will probably find that the options passed to open with rxtx are not the same as those passed by your other applications. This can be confirmed by looking at the strace outputs. The options may be incorrect assumptions on our part or a dusty corner of code in the driver. >From the strace output, the native code never made it past open. In some cases we try to hide problems in drivers like this. For instance, flushing wireless serial ports is usually not supported by the drivers - probably for real world reasons :). This case appears to be something that should not be worked around. The USB dongles present more complications - 100's of times more than traditional serial ports. There is an entire HID problem to deal with. JSR80 has a good outline of what is involved. With wireless and USB serial dongles, a prime assumption of rxtx and ttys in general is broken; they device may vanish. If the kernel driver does not handle this well, rxtx will fail. But from the rxtx perspective, it is just another tty using a well established interface. We have no special knowledge about the wireless aspects through our relatively small view of the device. >From the kernel driver side, presenting the device as a tty is often a nice to have or last minute addition. With feedback, they fall into place and work well. We saw this with USB Serial dongles. The goal would be to modify the simple program to reproduce the issue. You can look at SerialImp.c or even strace output to generate the series of calls and options required. If you can do that, then you can take rxtx out of the picture for the driver developers and present them with simple reproduction steps. That is the best way to get some feedback or fixes from them. "this simple program works but if I change this line, it fails" They may even say "that will never work because ..." in which case the rxtx developers would need to reconsider how we do things. More likely, you will find they just had not considered the use case and need to look at their code again. You may end up facilitating a fix that impacts many devices. On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. > And the remote device itself is a "pico plug" so access there either. > > as soon as i use rxtx to open the port, crash, but other software tools > work without problems. > I need some workaround to connect. > > regards, > Ritchie > > > Trent Jarvi wrote: >> >> >> As Uncle George says, you are best off trying to communicate the >> problem to the driver author clearly with as simple of an example as >> possible. If you can get a fix in the driver, it will help more than >> just rxtx using applications. >> >> While you persue the above, you may be able to avoid a quick >> open/close in rxtx by using a 'specified port' as documented in the >> INSTALL document that comes with rxtx source: >> >> ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7/INSTALL >> >> Q. How does rxtx detect ports? Can I override it? >> >> rxtx tries to detect ports on by scanning /dev for files matching any >> of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. >> Any ones that exist, are supposed to be good for the current operating >> system, and that can be read and written are offered back from >> CommPortIdentifier.getPortIdentifiers(), and only these can be used as >> ports. >> >> If you wish, you can set the system properties gnu.io.rxtx.SerialPorts >> and gnu.io.rxtx.ParallelPorts. If either of these is set, then no >> scanning will be carried out and only the specified ports will be >> available. You can use this to make one platform look like another, >> to restrict Java access to ports, or possibly for other reasons. For >> example >> >> java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp >> >> will look kind of like Solaris, if you have created the appropriate >> device nodes. >> >> A note on Linux port enumeration. We have set most ports aside. Once >> the >> number of possible devices started getting into the thousands, >> checking them >> all made little sense. Look in RXTXCommDriver.java and search for Linux. >> >> You will see that only /dev/ttyS* is searched but the possible >> addition ports >> that can be used are listed under it. Just copy the few you need. >> >> >> >> >> On Sun, 10 Feb 2008, Richard van Nieuwenhoven wrote: >> >>> yes, still the small test program. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. >>> >>> now to get rxtx working, is there a possibility to insert a delay / >>> timeout value ... >>> >>> regards, >>> Ritchie >>> >>> U. George wrote: >>>> Richard van Nieuwenhoven wrote: >>>>> Hi, >>>>> >>>>> now i tried a lot of combinations of settings and other >>>>> combinations in >>>>> the test source. >>>>> the crash happens if between the tcgetattr and the "close of the >>>>> file-descriptor" or "exit of the program" >>>>> there is no sleep, as soon as i include a sleep the test works as >>>>> expected. >>>> >>>> I'm a bit confused. are you still describing the small test program? >>>> Or are you describing rxtx? >>>> >>>> can u open(), close(), lets say 10 times in a row? >>>> can you open(), tcgetattr(), close(), 10 times in a row? >>>> >>>> In any case this issue, i think, has to be reported to the device >>>> driver maintainer for their evaluation. >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> > From netbeans at gatworks.com Sun Feb 10 15:58:35 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 10 Feb 2008 17:58:35 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF59F7.7070700@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> Message-ID: <47AF819B.7010204@gatworks.com> Richard van Nieuwenhoven wrote: > as i specified in my original post is already use this setting > -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. > > There is no specialized device driver, it is just a standard bluetooth > serial device. Maybe not specialized, but there are a set of device drivers for all of USB land. 1 for the USB controller 1 for the USB ( bluetooth ) device. 1 for the usb-serial translater. If u boot up your system without the bluetooth device, and later hot-plug in the bluetooth device, an entry should be made in var/log/messages. One of the entries will be the name of the bluetooth device driver discovered from the Manufacture ID, and Product ID. If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >>> >>> with the sleep or the valid read / write i can open and close the port >>> any number of times without any troubles. >>> but as soon as the tcgetattr and close are to fast after each other or >>> without write/read the device crashes. Then the device driver protocols are being violated. Delays, as you suggest, should be managed within the OS. From tjarvi at qbang.org Sun Feb 10 20:56:29 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 10 Feb 2008 20:56:29 -0700 (MST) Subject: [Rxtx] The next release. Message-ID: We have run into a stumbling block in the next release of rxtx. It appears that Sun has opened up threading a bit which causes problems in our current model. This is showing up as deadlocks. While they opened up the threading issues, their move was predated with atomic locks that solve the problem(?). The solution works in jdk 1.4 and beyond. In 1.3 and prior there are issues solvable by a requirement of other packages. So I'm wondering what we should do; what is reasonable. Should we drop support for 1.3 and point people to 2.1-7? Should we pull the older JREs forward and require third party add ons? I'm thinking we did well enough for 1.3 and we should just move forward. Are there any objections? Greg is offering to work out the threading issues and is asking if we require support for jre 1.3 and earlier. I really want to get past this and move rxtx into the computing cloud so everyone can make use of a working build environment. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Feb 11 03:29:20 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 05:29:20 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <47B02380.6020701@gatworks.com> Trent Jarvi wrote: > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. maybe you can explain what is different in the threading model to warrant the contemplated effort to correct. From arnab.bhaumik at gmail.com Mon Feb 11 06:05:53 2008 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 11 Feb 2008 18:35:53 +0530 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: move forward.............................. thats the feedback from my side............. who use rxtx professionally.......... On Feb 11, 2008 3:59 PM, U. George wrote: > Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > in > > our current model. This is showing up as deadlocks. > > maybe you can explain what is different in the threading model to > warrant the contemplated effort to correct. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Arnab Bhaumik / VU2BPW Proprietor and Design Engineer, AB Telecomm. Rajchandrapur, PO- Ghoshpara(Bally). Howrah, West Bengal. Pin - 711227 Ph- (033) 26716307 Mob- 9433927150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/dc145d51/attachment-0028.html From netbeans at gatworks.com Mon Feb 11 07:13:16 2008 From: netbeans at gatworks.com (U. George) Date: Mon, 11 Feb 2008 09:13:16 -0500 Subject: [Rxtx] Fwd: The next release. In-Reply-To: References: <47B02380.6020701@gatworks.com> Message-ID: <47B057FC.1030809@gatworks.com> > Pin - 711227 > Ph- (033) 26716307 > Mob- 9433927150 May I ask what is a PIN? MOB? I suppose the "Ph" means phone. From j.kenneth.gentle at acm.org Mon Feb 11 07:24:52 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Feb 2008 09:24:52 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Trent: While I don't have a need for this at the moment, I seem to remember other posts on this list talking about use of RXTX in mobile environments or other "limited device" environments. J2ME is still, unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude J2ME environments. I didn't do a search of the archives and may be mis-remembering the use of RXTX with J2ME environments. FWIW... Ken On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we drop > support for 1.3 and point people to 2.1-7? Should we pull the older JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > 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/20080211/4bc826a6/attachment-0027.html From bschlining at gmail.com Mon Feb 11 11:48:32 2008 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 11 Feb 2008 10:48:32 -0800 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: RXTX 2.1.7 already runs on 1.3. My recommendation would be:1) clearly tag or branch that version in CVS 2) add a post on the web site indicating that users who need 1.3 to use the 2.1.7 branch. 3) Fix the deadlock issues and let users know that it requires Java 1.4+ On Feb 11, 2008 6:24 AM, Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember other > posts on this list talking about use of RXTX in mobile environments or other > "limited device" environments. J2ME is still, unfortunately, stuck in a > Java 1.3 compatible subset of Java. Migration to 1.4 without maintaining > 1.3 _runtime_ compatibility would exclude J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use of > RXTX with J2ME environments. > > FWIW... > > Ken > > > On Feb 10, 2008 10:56 PM, Trent Jarvi wrote: > > > > > We have run into a stumbling block in the next release of rxtx. > > > > It appears that Sun has opened up threading a bit which causes problems > > in > > our current model. This is showing up as deadlocks. > > > > While they opened up the threading issues, their move was predated with > > atomic locks that solve the problem(?). > > > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > > issues solvable by a requirement of other packages. > > > > So I'm wondering what we should do; what is reasonable. Should we drop > > support for 1.3 and point people to 2.1-7? Should we pull the older > > JREs > > forward and require third party add ons? > > > > I'm thinking we did well enough for 1.3 and we should just move forward. > > Are there any objections? > > > > Greg is offering to work out the threading issues and is asking if we > > require support for jre 1.3 and earlier. > > > > I really want to get past this and move rxtx into the computing cloud so > > everyone can make use of a working build environment. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > 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 > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080211/3f3c2b2f/attachment-0027.html From ajmas at sympatico.ca Mon Feb 11 17:24:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 11 Feb 2008 19:24:27 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> I would be for moving forward, but keeping 1.3 support in its own branch. That way we can still tweak it as necessary and provide a solution for those stuck with that VM. As for the J2ME requirement, are there any special considerations which we should be making that aren't being made at this point? Andre On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > > We have run into a stumbling block in the next release of rxtx. > > It appears that Sun has opened up threading a bit which causes > problems in > our current model. This is showing up as deadlocks. > > While they opened up the threading issues, their move was predated > with > atomic locks that solve the problem(?). > > The solution works in jdk 1.4 and beyond. In 1.3 and prior there are > issues solvable by a requirement of other packages. > > So I'm wondering what we should do; what is reasonable. Should we > drop > support for 1.3 and point people to 2.1-7? Should we pull the older > JREs > forward and require third party add ons? > > I'm thinking we did well enough for 1.3 and we should just move > forward. > Are there any objections? > > Greg is offering to work out the threading issues and is asking if we > require support for jre 1.3 and earlier. > > I really want to get past this and move rxtx into the computing > cloud so > everyone can make use of a working build environment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ritchie at gmx.at Tue Feb 12 09:15:10 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 17:15:10 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47AF819B.7010204@gatworks.com> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> Message-ID: <47B1C60E.9050403@gmx.at> Hi, ok, i will try different usb-ports and usb-hubs for the bluetooth plug, other operating systems and versions, and another bluetooth plug in the next days and report the results. regards, Ritchie U. George wrote: > Richard van Nieuwenhoven wrote: >> as i specified in my original post is already use this setting >> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >> >> There is no specialized device driver, it is just a standard bluetooth >> serial device. > Maybe not specialized, but there are a set of device drivers for all > of USB land. > 1 for the USB controller > 1 for the USB ( bluetooth ) device. > 1 for the usb-serial translater. > If u boot up your system without the bluetooth device, and later > hot-plug in the bluetooth device, an entry should be made in > var/log/messages. One of the entries will be the name of the bluetooth > device driver discovered from the Manufacture ID, and Product ID. > If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. > > >>>> >>>> with the sleep or the valid read / write i can open and close the port >>>> any number of times without any troubles. >>>> but as soon as the tcgetattr and close are to fast after each other or >>>> without write/read the device crashes. > Then the device driver protocols are being violated. Delays, as you > suggest, should be managed within the OS. > From sebastien.jean.rxtx at gmail.com Tue Feb 12 11:23:31 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Tue, 12 Feb 2008 19:23:31 +0100 Subject: [Rxtx] read() not blocking In-Reply-To: <47ACCAE8.3020009@nextbus.com> References: <47ACCAE8.3020009@nextbus.com> Message-ID: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> I have posted such a mail a few weeks ago. I have experienced such weird behaviour, only under windows with the same binary. Seems to be a native problem. My workaround is to set a receive timeout, with a large value. Working but ugly solution... Baz Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > I found an issue today under the Windows version of rxtx-2.0-7pre1 > (the > latest prebuilt binary which supports javax.comm). Turns out that > read() from a serial port InputStream sometimes returns -1 when it > should block instead. This is not a problem under Linux. > > Because of this, there is no way to do fundamental stuff like wrap the > InputStream in an InputStreamReader and perform a readLine(), since an > IOException gets thrown: "Underlying input stream returned zero > bytes". > My workaround is simply to read one byte at a time from the > InputStream and ignore when -1 is returned. > > Seems like others have encountered this in the past: > > http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html > http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html > > I second Knute's opinion: this does seem to be a rather serious bug! > > Any word on a fix for this? If so, is there a binary version of the > software built which contains the fix? > > > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Feb 12 14:02:26 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 12 Feb 2008 15:02:26 -0600 Subject: [Rxtx] The next release. In-Reply-To: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> Message-ID: <47B20962.9030408@cox.net> Ken Gentle wrote: > Trent: > > While I don't have a need for this at the moment, I seem to remember > other posts on this list talking about use of RXTX in mobile > environments or other "limited device" environments. J2ME is still, > unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration > to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude > J2ME environments. > > I didn't do a search of the archives and may be mis-remembering the use > of RXTX with J2ME environments. In the end, I'd personally prefer that the branch be at JDK1.5 since that is the VM version where the SPECs say that volatile works as needed and the Atomic* classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, but what about other VMs? Gregg Wonderly From ritchie at gmx.at Tue Feb 12 14:15:58 2008 From: ritchie at gmx.at (Richard van Nieuwenhoven) Date: Tue, 12 Feb 2008 22:15:58 +0100 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B1C60E.9050403@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> Message-ID: <47B20C8E.9030501@gmx.at> Hi, First of all SOLVED (for me)!!! It was a question of timeout's.... at first i was not successful after trying: 1>suse linux 10.0 kernel 2.6.13 1>bluetooth pcmcia card 2>suse linux 10.1 kernel 2.6.16 2>usb bluetooth dongle direct to the controller 3>suse linux 10.1 kernel 2.6.16 3>usb bluetooth dongle in a usb-2.0 hub at last i thought of looking on the bluez (linux bluetooth api) website and found it there in the FAQ (included it in the bottom of the mail). So i tried running "rfcomm connect /dev/rfcomm0" (with blocks....) iand running the test program in the other terminal, YES it functions! Now i tried rxtx in java and YES now it works, as long i have "rfcomm connect /dev/rfcomm0" running in another terminal. The messages are: - i would recommend rxtx should include the rfcomm faq entry in there faq - it would be great when rxtx would include a feature (as a system.property?) to delay after the opening of a port to enable slow serial bluetooth devices. Thanks for all your help, i can work with this workaround, and i would be happy to help you test the any type delay feature you implement in the hopefully near future. regards, Richard van Nieuwenhoven --FAQ from bluez ------------------------------------ 18. RFCOMM connection using minicom or other tool fails? In case you have created the RFCOMM link using the "rfcomm bind" function this can be caused by application timeouts. This is not a problem of BlueZ or the RFCOMM implementation but rather a problem with the different nature of a RFCOMM virtual TTY and a physical serial TTY device which is normally used by those applications. Some applications implement a timeout protection function while opening the port. If opening the port takes longer than a certain amount of time then the application fails. A serial TTY will usually only take several microseconds to open while the RFCOMM virtual TTY can take several seconds. Try to create the connection before starting your application. This can be done by the "rfcomm connect" function. The Bluetooth connection will then remain until the rfcomm utility is stopped. -------------------------------------- Richard van Nieuwenhoven wrote: > Hi, > > ok, i will try different usb-ports and usb-hubs for the bluetooth plug, > other operating systems and versions, and another bluetooth plug in the > next days and report the results. > > regards, > Ritchie > > > U. George wrote: > >> Richard van Nieuwenhoven wrote: >> >>> as i specified in my original post is already use this setting >>> -Dgnu.io.rxtx.SerialPorts... I need it to connect to rfcomm0. >>> >>> There is no specialized device driver, it is just a standard bluetooth >>> serial device. >>> >> Maybe not specialized, but there are a set of device drivers for all >> of USB land. >> 1 for the USB controller >> 1 for the USB ( bluetooth ) device. >> 1 for the usb-serial translater. >> If u boot up your system without the bluetooth device, and later >> hot-plug in the bluetooth device, an entry should be made in >> var/log/messages. One of the entries will be the name of the bluetooth >> device driver discovered from the Manufacture ID, and Product ID. >> If it does connect to usb-serial, then a /dev/ttyUSB0 would be created. >> >> >> >>>>> with the sleep or the valid read / write i can open and close the port >>>>> any number of times without any troubles. >>>>> but as soon as the tcgetattr and close are to fast after each other or >>>>> without write/read the device crashes. >>>>> >> Then the device driver protocols are being violated. Delays, as you >> suggest, should be managed within the OS. >> >> > > > > From noky at nextbus.com Tue Feb 12 14:39:30 2008 From: noky at nextbus.com (Mike Charnoky) Date: Tue, 12 Feb 2008 16:39:30 -0500 Subject: [Rxtx] read() not blocking In-Reply-To: <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> References: <47ACCAE8.3020009@nextbus.com> <395F7C50-4AA9-4097-BDAF-8B25736329E6@gmail.com> Message-ID: <47B21212.80808@nextbus.com> Thanks. I have already tried this technique, using serialPort.enableReceiveTimeout(Integer.MAX_VALUE). The read still returns -1 about every 40 seconds. My workaround is to read() one byte at a time and ignore when it returns -1. Ugly. My main concern is that this eventually gets fixed so that other people do not experience the same frustration! Mike Sebastien Jean wrote: > I have posted such a mail a few weeks ago. > I have experienced such weird behaviour, only under windows with the > same binary. > Seems to be a native problem. > > My workaround is to set a receive timeout, with a large value. > Working but ugly solution... > > > Baz > > Le 8 f?vr. 08 ? 22:34, Mike Charnoky a ?crit : > >> I found an issue today under the Windows version of rxtx-2.0-7pre1 (the >> latest prebuilt binary which supports javax.comm). Turns out that >> read() from a serial port InputStream sometimes returns -1 when it >> should block instead. This is not a problem under Linux. >> >> Because of this, there is no way to do fundamental stuff like wrap the >> InputStream in an InputStreamReader and perform a readLine(), since an >> IOException gets thrown: "Underlying input stream returned zero bytes". >> My workaround is simply to read one byte at a time from the >> InputStream and ignore when -1 is returned. >> >> Seems like others have encountered this in the past: >> >> http://mailman.qbang.org/pipermail/rxtx/2006-September/1982267.html >> http://mailman.qbang.org/pipermail/rxtx/2007-March/1888561.html >> >> I second Knute's opinion: this does seem to be a rather serious bug! >> >> Any word on a fix for this? If so, is there a binary version of the >> software built which contains the fix? >> >> >> Mike >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Tue Feb 12 14:57:24 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 12 Feb 2008 14:57:24 -0700 Subject: [Rxtx] The next release. In-Reply-To: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> References: <87C5C80D-186D-4E5A-8D46-73947B596C3F@sympatico.ca> Message-ID: <47B21644.2050309@ergotech.com> Sort of unrelated, I'm getting confused about releases and backwards compatibility. Some of the J2ME platforms provide their own JavaComm API. So as important to us as JVM support is compatibility with older Sun API's. It'll be a long time, probably 5 years+ until some of these are updated. In the last couple of weeks we finally stopped supporting our last Personal Java a.k.a. JDK1.1.7 platform - yeah!!! We're now starting to be able to support some of the ARM platforms using JAMVM. I haven't tried RXTX on these yet. Thanks, and sorry for not following along too closely. Jim Andre-John Mas wrote: > I would be for moving forward, but keeping 1.3 support in its own > branch. That way we can still tweak it as necessary and provide > a solution for those stuck with that VM. > > As for the J2ME requirement, are there any special considerations > which we should be making that aren't being made at this point? > > > Andre > > On 10-Feb-08, at 22:56 , Trent Jarvi wrote: > >> We have run into a stumbling block in the next release of rxtx. >> >> It appears that Sun has opened up threading a bit which causes >> problems in >> our current model. This is showing up as deadlocks. >> >> While they opened up the threading issues, their move was predated >> with >> atomic locks that solve the problem(?). >> >> The solution works in jdk 1.4 and beyond. In 1.3 and prior there are >> issues solvable by a requirement of other packages. >> >> So I'm wondering what we should do; what is reasonable. Should we >> drop >> support for 1.3 and point people to 2.1-7? Should we pull the older >> JREs >> forward and require third party add ons? >> >> I'm thinking we did well enough for 1.3 and we should just move >> forward. >> Are there any objections? >> >> Greg is offering to work out the threading issues and is asking if we >> require support for jre 1.3 and earlier. >> >> I really want to get past this and move rxtx into the computing >> cloud so >> everyone can make use of a working build environment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 ajmas at sympatico.ca Tue Feb 12 18:02:18 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 12 Feb 2008 20:02:18 -0500 Subject: [Rxtx] Serial device crashes on port scan In-Reply-To: <47B20C8E.9030501@gmx.at> References: <47ACDD94.6090402@gmx.at> <47ACED74.9010704@gatworks.com> <47ADF499.60808@gmx.at> <47AE2C5F.3050904@gmx.at> <47AF2A1A.2020607@gmx.at> <47AF3228.3010502@gatworks.com> <47AF3479.2000707@gmx.at> <47AF59F7.7070700@gmx.at> <47AF819B.7010204@gatworks.com> <47B1C60E.9050403@gmx.at> <47B20C8E.9030501@gmx.at> Message-ID: > > The messages are: > - i would recommend rxtx should include the rfcomm faq entry in > there faq If you have a good description, then I would recommend that you add it to the FAQ in the Wiki. You just need to create yourself an account and then you are free to add any information you think might be missing. Andre From tjarvi at qbang.org Tue Feb 12 18:31:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Feb 2008 18:31:17 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B20962.9030408@cox.net> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: On Tue, 12 Feb 2008, Gregg Wonderly wrote: > Ken Gentle wrote: >> Trent: >> >> While I don't have a need for this at the moment, I seem to remember >> other posts on this list talking about use of RXTX in mobile >> environments or other "limited device" environments. J2ME is still, >> unfortunately, stuck in a Java 1.3 compatible subset of Java. Migration >> to 1.4 without maintaining 1.3 _runtime_ compatibility would exclude >> J2ME environments. >> >> I didn't do a search of the archives and may be mis-remembering the use >> of RXTX with J2ME environments. > > In the end, I'd personally prefer that the branch be at JDK1.5 since that is the > VM version where the SPECs say that volatile works as needed and the Atomic* > classes are available. Sun's later 1.4 VMs had the 1.5 implementation in them, > but what about other VMs? > 1.5 feels like the right target. We could branch and (sigh) fork for embeded devices AKA the ToyBox. The branch could target jre 1.3 if everyone agrees. But that would not be as bad as the bitrotting 2.0 branch for javax.comm support. The differences would be in the java code. The native code would be nearly identical making it easy to maintain. Our java code does not really change that much. That said, I'm just poking and feeling at this point. We have a couple solutions and tests on my side and a few others out there. I can test and share the results for any option provided. I'm actually reading up on conurrency in recent Javas now. I can provide a solution but it sounds like others have seen this show before. Maybe the jre 1.5 target brings performance wins. Maybe not. I'd think the right thing to do is give 1.5 volatiles/atomics a chance. If they perform well with single byte read/write bitbanging, we should go with 1.5. If there is no measurable advantage, then forking a branch makes little sense - unless we consider the performance degredation for embeded devices using jre 1.3. The reason I've sortof steeped back and suggest we look at this carefully is the embeded target implications. All of the solutions we have now provide nothing but performance degredation for the embeded targets. They don't need what what we have wether it uses heavy handed synchronization or concurrency Atomics. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Wed Feb 13 16:35:46 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 14 Feb 2008 00:35:46 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Hi Trent, sorry for not following the list for a while... > It appears that Sun has opened up threading a bit which > causes problems in > our current model. This is showing up as deadlocks. When I understand you right, you're saying that the threading behaves differently in newer JVMs than older ones; and one must use newer language features to deal with that in the newer JVM's. Can you give me any additional pointers to more information about these issues? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From netbeans at gatworks.com Wed Feb 13 17:34:33 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 13 Feb 2008 19:34:33 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> Message-ID: <47B38C99.9090903@gatworks.com> > That said, I'm just poking and feeling at this point. We have a couple > solutions and tests on my side and a few others out there. What you have not said is what the ( concrete ) problem is that you are providing a solution for? If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. From tjarvi at qbang.org Wed Feb 13 18:28:41 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:28:41 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B38C99.9090903@gatworks.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com> <47B20962.9030408@cox.net> <47B38C99.9090903@gatworks.com> Message-ID: On Wed, 13 Feb 2008, U. George wrote: > >> That said, I'm just poking and feeling at this point. We have a couple >> solutions and tests on my side and a few others out there. > > What you have not said is what the ( concrete ) problem is that you are > providing a solution for? > > If you have an ( deadlock ? ) issue, just post the test. I'd love to see it. > This is the same deadlock issue that you provided a patch for. That patch works fine except for small read and writes which takes a performance hit. I'll look to see if there is a simpler way to reproduce the problem that does not involve a dvd of software. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 13 18:49:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 13 Feb 2008 18:49:57 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > Hi Trent, > > sorry for not following the list for a while... > >> It appears that Sun has opened up threading a bit which >> causes problems in >> our current model. This is showing up as deadlocks. > > When I understand you right, you're saying that the > threading behaves differently in newer JVMs than older > ones; and one must use newer language features to > deal with that in the newer JVM's. There are Atomic concurrency offerings in newer JREs that may solve a problem introduced in the 1.5 JREs as threading was opened up exposing code in rxtx that was not thread safe. Traditional synchronization also works but degrades performance in bitbang like activities. Prior to 1.4 JREs we did not experience problems but that does not imply our code was thread safe. Many applications probably do not see the problem. This article appears to touch on all the important bits we are discussing on the solution end: http://www.ibm.com/developerworks/java/library/j-jtp11234/ I don't have a good link to the threading issues introduced at this time. The above just discusses the proposed solution. I have reliably reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 though. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Feb 14 14:25:07 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 14 Feb 2008 15:25:07 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> Message-ID: <47B4B1B3.1040704@cox.net> Trent Jarvi wrote: > On Thu, 14 Feb 2008, Oberhuber, Martin wrote: > >> Hi Trent, >> >> sorry for not following the list for a while... >> >>> It appears that Sun has opened up threading a bit which >>> causes problems in >>> our current model. This is showing up as deadlocks. >> When I understand you right, you're saying that the >> threading behaves differently in newer JVMs than older >> ones; and one must use newer language features to >> deal with that in the newer JVM's. > I don't have a good link to the threading issues introduced at this time. > The above just discusses the proposed solution. I have reliably > reproduced deadlocks in a MATLAB test enivornment since moving to JRE 1.5 > though. The primary issue is that people now have access to multi-processor environments where concurrency bugs are now visible. One thing which changed in 1.5 is the Java Memory Model was enhanced to specify how volatile works now. The specific issue was about visibility of changes to a variable value that is volatile. This, is not a big issue in many cases, but it is a vital thing to understand if you have ever written (incorrect) code such as class foo implements Runnable { boolean done; public void shutdown() { done = true; } public void run() { while( !done ) { // code that never references done } } } In the 1.5 Sun JVM, this code, which was always incorrectly written, simply stopped working on uniprocessor and mulitprocessor machines because the compiler was given knowledge of volatile. What happens is that run() becomes rewritten by the optimizer to be public void run() { if( !done ) { while( true ) { // code that never references done } } } The fact that done is not marked as volatile, allows the compiler to assume that no other thread will ever change the value, and thus when it inspects the flow of the internal loop, it sees that done is never written and thus it can remove that reference from the loop parameterization, because, it believes it will never change! If you change done to be declared as volatile, or if you add synchronized access to it, then it will work correctly public void synchronized shutdown() { done = true; } public void run() { while( true ) { synchronized( this ) { if( done ) break; } ... body of loop... } } is one of the safe ways to write such a class structure using synchronized. Because many didn't have multiprocessor systems available for running java code, incorrect/unsafe coding practices still resulted in working applications on uniprocessor machines, and sometimes even multi-processor machines. The deadlock in the code that we've been throwing back and forth here was specifically because an integer value was unsafely modified by -- and ++, in unsynchronized code, and this allowed the value to go through a sequence of changes that did not correctly modify the value. I.e. as Brian says on the referenced web page, -- and ++ are not atomic operations, they are three sequential operations, read, modify, write. If those are interleaved appropriately, we can see read-a read-b modify-b modify-a write-b write-a which means that one of the changes (the -b change) is lost. The deadlock occurred when a dereference decrement was lost and close() set and waited forever for a pending read/write to complete. Gregg Wonderly From netbeans at gatworks.com Thu Feb 14 20:46:16 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 14 Feb 2008 22:46:16 -0500 Subject: [Rxtx] The next release. In-Reply-To: <47B4B1B3.1040704@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> Message-ID: <47B50B08.8040606@gatworks.com> > > The fact that done is not marked as volatile, allows the compiler to assume that > no other thread will ever change the value, and thus when it inspects the flow > of the internal loop, it sees that done is never written and thus it can remove > that reference from the loop parameterization, because, it believes it will > never change! I think u'r example is faulty. the variable 'done' is initially false, and can be changed via shutdown(). If javac produces the code that you suggest, then the compiler is defective ( which is not likely ). > > If you change done to be declared as volatile, or if you add synchronized access > to it, then it will work correctly > > public void synchronized shutdown() { > done = true; > } > > public void run() { > while( true ) { > synchronized( this ) { > if( done ) > break; > } > ... body of loop... > } > } > If you change your program, such that the possibility that the variable 'done' is not alterable, then the volatile attribute would keep the variable alive, rather then being optimized out of existence. AND since the variable 'done' cannot be changed, in your example, one has to question why you would add volatile at all. Now if you add in native routines, that has access to the objects java environment, then 'done' can *change* by the native routine unbeknownst the the javac compiler. In this case, adding volatile is necessary, as it gives the javac compiler a heads-up that the data may change by alternate means. Using synchronize, does not appear to overcome the optimizer's duty to eliminate the variable 'done'. Your usage of synchronized to prevent such optimizations appears faulty. From michael.erskine at ketech.com Fri Feb 15 03:58:13 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 15 Feb 2008 10:58:13 +0000 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B7988@no-sv-03.ketech.local> Guys, The place to go for the true operation of recent Java versions is the Java Language Specification v3.0: http://java.sun.com/docs/books/jls/ . Any argument should reference it to resolve any differences. Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Feb 15 14:19:51 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 15 Feb 2008 22:19:51 +0100 Subject: [Rxtx] The next release. In-Reply-To: References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> > This is the same deadlock issue that you provided a patch > for. That patch > works fine except for small read and writes which takes a > performance hit. Then I'm in favor of committing that patch to CVS and dealing with the performance hit afterwards. IMHO correctness is MUCH more important than performance. Do we know of any concrete applicatons that are negatively impacted by the performance hit? Have we profiled RXTX to know where the performance hit really occurs? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From tjarvi at qbang.org Fri Feb 15 18:36:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 15 Feb 2008 18:36:13 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 15 Feb 2008, Oberhuber, Martin wrote: > >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > The test I want to do involves asynchronous reading and writing of single bytes combined with opening and closing the port. I'll come up with a test using loopback this weekend and share the results. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Sat Feb 16 08:50:28 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Sat, 16 Feb 2008 10:50:28 -0500 Subject: [Rxtx] The next release. In-Reply-To: <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> References: <670b66630802110624x4e510777vd2837da9ad06f19a@mail.gmail.com><47B20962.9030408@cox.net><47B38C99.9090903@gatworks.com> <460801A4097E3D4CA04CC64EE64858480480615D@ism-mail03.corp.ad.wrs.com> Message-ID: <47B70644.4070405@gmail.com> Oberhuber, Martin wrote: >> This is the same deadlock issue that you provided a patch >> for. That patch >> works fine except for small read and writes which takes a >> performance hit. >> > > Then I'm in favor of committing that patch to CVS and > dealing with the performance hit afterwards. IMHO > correctness is MUCH more important than performance. > > Do we know of any concrete applicatons that are > negatively impacted by the performance hit? Have > we profiled RXTX to know where the performance hit > really occurs? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, I created one of those applications (codeskin.com) that takes a significant performance hit when either synchronized statements or atomic integers are used to make IOLocked thread-safe. Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080216/a04ebd3a/attachment-0022.html From mringwal at inf.ethz.ch Sun Feb 17 03:57:11 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Sun, 17 Feb 2008 11:57:11 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > 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'd like to throw in an even more radical approach: Re-write RXTX to use Java Native Access (JNA) https://jna.dev.java.net/ JNA allows to call a native method (POSIX API, win32, Solaris..) by specifying the function prototype in Java and having some magic involving the libffi project to dynamically call anything. No compilation, etc.. Two drawbacks: - re-implement the native code of rxtx - there is a performance loss.. no. I'm not advocating this, I just want to show the possibility. cheers matthias From tjarvi at qbang.org Sun Feb 17 11:11:36 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 17 Feb 2008 11:11:36 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Matthias Ringwald wrote: > > > On 08.01.2008, at 14:12, Dr. Douglas Lyon wrote: > >> 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'd like to throw in an even more radical approach: > Re-write RXTX to use Java Native Access (JNA) > https://jna.dev.java.net/ > > JNA allows to call a native method (POSIX API, win32, Solaris..) > by specifying the function prototype in Java and having some magic > involving the libffi project to dynamically call anything. > > No compilation, etc.. > > Two drawbacks: > - re-implement the native code of rxtx > - there is a performance loss.. > > no. I'm not advocating this, I just want to show the possibility. > Hi Matthias It is not out of model in rxtx to try something like this. There is a tree in rxtx source that experiements with gcj for instance. If you want to put something together, we can add it to the project. -- Trent Jarvi tjarvi at qbang.org From mringwal at inf.ethz.ch Mon Feb 18 03:02:47 2008 From: mringwal at inf.ethz.ch (Matthias Ringwald) Date: Mon, 18 Feb 2008 11:02:47 +0100 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <1092E99F-BBD8-446D-8347-5B030211C2DB@inf.ethz.ch> Hi Trent thanks for the offer/help. I don't have anytime for this and I am quite happy with the standard way of installing rxtx using configure/ make/install. I just realized that multi-platform support/webstart/... etc does regularly show up on this list. In addition, in my toy project libxine-java I also had to figure out how to build a JNI in a multi-platform fashion. I did look at maven plugins and other solution, but couldn't find one which would also take care of JAWT (native access to java windowing stuff). I settled on using libtool (multi-platform shared libraries) and some bash scripts to find the java header and other dependent libraries. I don't like providing any information to configure (especially not paths, if not necessary). And JNA could provide a Java-only implementation. cheers, matthias On 17.02.2008, at 19:11, Trent Jarvi wrote: > Hi Matthias > > It is not out of model in rxtx to try something like this. There is > a tree in rxtx source that experiements with gcj for instance. > > If you want to put something together, we can add it to the project. > > -- > Trent Jarvi > tjarvi at qbang.org From gergg at cox.net Mon Feb 18 12:00:55 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 18 Feb 2008 13:00:55 -0600 Subject: [Rxtx] The next release. In-Reply-To: <47B50B08.8040606@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> Message-ID: <47B9D5E7.2000800@cox.net> U. George wrote: >> The fact that done is not marked as volatile, allows the compiler to assume that >> no other thread will ever change the value, and thus when it inspects the flow >> of the internal loop, it sees that done is never written and thus it can remove >> that reference from the loop parameterization, because, it believes it will >> never change! > I think u'r example is faulty. the variable 'done' is initially false, > and can be changed via shutdown(). If javac produces the code that you > suggest, then the compiler is defective ( which is not likely ). You can try this if you'd like. It does happen as I've described, and Sun engineers on the concurrency mailing list provided me the information about what was happening. I think it is a nasty feature. >> If you change done to be declared as volatile, or if you add synchronized access >> to it, then it will work correctly >> >> public void synchronized shutdown() { >> done = true; >> } >> >> public void run() { >> while( true ) { >> synchronized( this ) { >> if( done ) >> break; >> } >> ... body of loop... >> } >> } >> > If you change your program, such that the possibility that the variable > 'done' is not alterable, then the volatile attribute would keep the > variable alive, rather then being optimized out of existence. Yes, I didn't illustrate the use of volatile. My point was that it was incorrect to "ever" have a shutdown mechanism coded as I coded it. Another thread calling shutdown, would in fact change done, but that change would never stop the loop from terminating once a thread was inside of it. > AND since > the variable 'done' cannot be changed, in your example, one has to > question why you would add volatile at all. It can be changed by another thread calling shutdown. > Now if you add in native routines, that has access to the objects java > environment, then 'done' can *change* by the native routine unbeknownst > the the javac compiler. In this case, adding volatile is necessary, as > it gives the javac compiler a heads-up that the data may change by > alternate means. > > Using synchronize, does not appear to overcome the optimizer's duty to > eliminate the variable 'done'. Your usage of synchronized to prevent > such optimizations appears faulty. I think I may not have done a good job explaining all the details. The Sun 1.5 JVM really does/did (the optimizer may have been changed at some point, but I don't believe it was) behave this way. Try it on a uniprocessor and a multiprocessor and see what you find. You can write a simple JFrame based application that scrolls things in a list. Put a button on there that calls shutdown and make the run() loop add items to the list and position to the end of the list, for example. Start a thread to do the run() loop, and the event thread will be the one calling shutdown. Don't use volatile or synchronized and see if you can recreate the behavior I described. Gregg Wonderly From tjarvi at qbang.org Mon Feb 18 16:02:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Feb 2008 16:02:00 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47B9D5E7.2000800@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: On Mon, 18 Feb 2008, Gregg Wonderly wrote: >> If you change your program, such that the possibility that the variable >> 'done' is not alterable, then the volatile attribute would keep the >> variable alive, rather then being optimized out of existence. > > Yes, I didn't illustrate the use of volatile. My point was that it was > incorrect to "ever" have a shutdown mechanism coded as I coded it. Another > thread calling shutdown, would in fact change done, but that change would never > stop the loop from terminating once a thread was inside of it. > >> AND since >> the variable 'done' cannot be changed, in your example, one has to >> question why you would add volatile at all. > > It can be changed by another thread calling shutdown. > >> Now if you add in native routines, that has access to the objects java >> environment, then 'done' can *change* by the native routine unbeknownst >> the the javac compiler. In this case, adding volatile is necessary, as >> it gives the javac compiler a heads-up that the data may change by >> alternate means. >> >> Using synchronize, does not appear to overcome the optimizer's duty to >> eliminate the variable 'done'. Your usage of synchronized to prevent >> such optimizations appears faulty. > > I think I may not have done a good job explaining all the details. The Sun 1.5 > JVM really does/did (the optimizer may have been changed at some point, but I > don't believe it was) behave this way. Try it on a uniprocessor and a > multiprocessor and see what you find. You can write a simple JFrame based > application that scrolls things in a list. Put a button on there that calls > shutdown and make the run() loop add items to the list and position to the end > of the list, for example. Start a thread to do the run() loop, and the event > thread will be the one calling shutdown. Don't use volatile or synchronized and > see if you can recreate the behavior I described. > Hi Gregg This does explain many things I'm seeing in rxtx, Sun's API (Sockets) and code I'm working with at work. I've been reading up on concurrency in Java like I said I would too. The following is my current thought process. They do not represent a final decision. I knew there was more too this when it first showed up and have tried to avoid making the wrong decision quickly. This feels like a coding break of contract perhaps from a perspective of one that learned to live in a single CPU core world. With respect to rxtx, there are a few options we have moving forward. One is to solve this with one of the patch sets submitted to the list to lock down java threads. They are not incorrect. We could look at derivatives too. A second option would be to take the locking into the native code (losing many eyes in the process). The idea there would be to avoid premature optimization in java by the compiler. A third option would be to get rid of the locking code and handle everything as the port shuts down. KISS I didn't think there was significant gain for the work in the third option. But now it appears to be the best option to avoid two issues: 1) losing eyes on the code. U. George and a few others look into the native side but not many. By the time you talk about w32 maybe 3 people look at that native code. 2) performance degredation. There is a third issue that we need to think about. The 1.3 JREs. There is interest on the list to move code to 1.5 conventions. But I think we can resolve this issue for 1.3 and 1.5 JREs before taking on that problem. A branch of rxtx looks likely but after we deal with this issue. A large part of my time has been spent trying to figure out what the issue is. I think we can create some test cases now that work on an SMP machine. I have some code here but my 10 year old laptop is single core :) I'll try it on a machine at work before posting. I'm against taking the path of being correct is better than being fast because the issue will not get attention after that for all practical purposes. The patches that do the correct portion are on the list. In fact, I'm using one of them on the side. We can discuss and test different approaches but close should just close IMO. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Mon Feb 18 17:34:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Mon, 18 Feb 2008 19:34:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Hello - First of all, thanks to all the developers for a wonderful library. Too bad Sun is too lazy to release a fully-portable serial port library, so thanks for filling in the gap. Now, on to my question: I am developing a Java WebStart application. The application interfaces with a barcode scanner attached to a RS-232 serial port. I followed Sun's WebStart instructions in creating the application. Also, I am using Andre-John Mas's RxTx jars and jnpl found at: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp . The program works fine on Linux. However, Windows is another story. Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). Sometimes, when no ports are discovered, I will plug a USB-Serial converter in. Oddly, I can see "COM1" after restarting my application. What is odd is that COM1 is built into the motherboard. COM3 is supposed to be the converter. Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is actually the USB-Serial converter, even though Windows says otherwise? Regardless, I have tried attaching the bar-code scanner to both ports, and neither work properly (I'll explain below). These symptoms occur on both Windows machines I have access to. The device has a very simple protocol. Receive X bytes, then send an ACK. Continue until EOM. Originally, inStream.read() would always return -1. Then I realized my timeout was too short and made it longer. It still returns -1 when the timeout occurs (as expected), but at least it now blocks. However, read never receives my data when I put the data on the line. This worked fine for me in Linux, but not in Windows. Now, the Java Console says that both the library and the native libs are RXTX-2.1-7, so I don't believe it is a mismatch. The Ports themselves look fine from Window's Control Panel (Baud, Stopbits, parity, conflicts, etc..) I am totally out of ideas.. My guess is there is a bug in the Window's native code, but maybe I am in fact doing something wrong. Any help or suggestions is greatly appreciated! -Paul From tjarvi at qbang.org Tue Feb 19 05:41:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 05:41:02 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> References: <748d0ca90802181634r6d1dcdfbu84e1fa3c2fc49a99@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Paul Giblock wrote: > Hello - > > program works fine on Linux. However, Windows is another story. > Sometimes, no portIdentifiers are discovered by getPortIdentifiers(). > Sometimes, when no ports are discovered, I will plug a USB-Serial > converter in. Oddly, I can see "COM1" after restarting my > application. What is odd is that COM1 is built into the motherboard. > COM3 is supposed to be the converter. > > Maybe Rxtx is improperly mapping IDs to the ports? Perhaps COM1 is > actually the USB-Serial converter, even though Windows says otherwise? > Regardless, I have tried attaching the bar-code scanner to both > ports, and neither work properly (I'll explain below). These symptoms > occur on both Windows machines I have access to. > > The device has a very simple protocol. Receive X bytes, then send an > ACK. Continue until EOM. Originally, inStream.read() would always > return -1. Then I realized my timeout was too short and made it > longer. It still returns -1 when the timeout occurs (as expected), > but at least it now blocks. However, read never receives my data when > I put the data on the line. This worked fine for me in Linux, but not > in Windows. > I would look outside of rxtx for the source of your problem. I'd check BIOS settings to see why the COM1 isnt showing up in the first place. COM1 and COM3 share an IRQ. The port showing up as COM1-4 sounds suspicious. Make sure you have the latest version of the driver for your USB dongle. Try to use a USB dongle with a namebrand you recognize. The quality of the drivers can vary significantly. Also try other software such as the terminal software that comes with windows. Make sure they are not open while enumerating ports with rxtx. Using rxtx see if you can ever determine that bytes are available. If you can't, the driver is probably suspect. -- Trent Jarvi tjarvi at qbang.org From mc354 at tid.es Tue Feb 19 07:40:00 2008 From: mc354 at tid.es (Miguel) Date: Tue, 19 Feb 2008 15:40:00 +0100 Subject: [Rxtx] rxtx problem Message-ID: <1203432000.8990.0.camel@McM> I got stack with the RXTX library and I dont understand why, the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver But It is supossed that the new library rxtx doesnt use javaxcomm ... I dont understand, Here is the exact line of code of the commPortIdentifier.java: Sync = new Object(); try { CommDriver RXTXDriver = (CommDriver) Class.forName("gnu.io.RXTXCommDriver").newInstance(); RXTXDriver.initialize(); } catch (Throwable e) { System.err.println(e + " thrown while loading " + "gnu.io.RXTXCommDriver"); } could anybody please help me?? Thank you in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080219/78f548f5/attachment-0019.html From mirek at host.sk Tue Feb 19 09:47:16 2008 From: mirek at host.sk (mirek) Date: Tue, 19 Feb 2008 17:47:16 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu Message-ID: <47BB0814.2060102@host.sk> hello i am newbie in 1-wire programming and at the moment i am trying to configure my development environment for this purpose. so: - i am running ubuntu server 7.10 with kernel 2.6.22-14 - i installed the package librxtx-java which provides the 2.1.7-2 version of rxtx - java -version: java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) - lsusb: Bus 001 Device 001: ID 0000:0000 Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter Bus 002 Device 001: ID 0000:0000 - dmesg|grep usb [ 27.316169] usbcore: registered new interface driver usbfs [ 27.316247] usbcore: registered new interface driver hub [ 27.316313] usbcore: registered new device driver usb [ 7.700000] usb usb1: configuration #1 chosen from 1 choice [ 7.810000] usb usb2: configuration #1 chosen from 1 choice [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice [ 21.080000] usbcore: registered new interface driver DS9490R [ 24.680000] usbcore: registered new interface driver usbserial [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic [ 24.680000] usbcore: registered new interface driver usbserial_generic [ 24.680000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB Serial Driver core - lsmod|grep usb usbserial 34920 0 usbcore 138760 4 usbserial,ds2490,uhci_hcd - version of onewireapi is 1.10 the problem is - i cannot make my ds9490r running. when i try to compile and run application, which just shows the available adapters, the output is: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapte where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info about existence of /dev/ttyUSBx files, but there is no such file in my /dev directory. for this purpose i loaded usbserial module, but this doesn't help. is link from /dev/ttyS0 just enough? or the problem is completly somewhere else? please - help ;) if you have some idea, where the problem could be, i will appreciate any hint. take care mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From gergg at cox.net Tue Feb 19 10:04:24 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 19 Feb 2008 11:04:24 -0600 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> Message-ID: <47BB0C18.9010102@cox.net> Trent Jarvi wrote: > We can discuss and test different approaches but close should just close > IMO. In general, managing the possibility of concurrency when there isn't any, is the issue at hand. If applications are written to use threading and thus create asynchrony in the interactions with RXTX I/O, it is generally best to let those applications deal with the issue as explicitly as they need to. The performance changes, are interesting to me. I'd think that the latency between bytes on a typically serial port application up to about 19,200 baud, would be significant compared to the latency injected in the concurrency artifacts. But, I don't have a place to examine the issues directly, so it's great to hear of your's and others' experiences. Gregg Wonderly From drfaygo at gmail.com Tue Feb 19 11:12:09 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Tue, 19 Feb 2008 13:12:09 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads Message-ID: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Trent - Thank you for the fast response. I have performed more debugging and have some, probably sad, news. My development system is a dual-boot Linux-Windows configuration. So, I installed Eclipse in Windows. I downloaded the 2.1-7 final stable library and native binaries just in case. Rxtx enumerates the same ports (COM3, COM4) as my other Windows software does, so this is good. However, reading from the port still results in no data. I can reboot into Linux and it works fine. I installed the program "Advanced Serial Port Terminal by Eltima Software", a glorified terminal. If I read from the serial port (COM4) I do, in fact, receive the first packet. If I set the software to send ACK responses every 100ms, then I receive all of my packets. So, it looks like the OS, BIOS, USB converter, and serial device are all working fine. One thing I did notice: Sometimes Windows detects my device as a "Microsoft Serial BallPoint". This is shown under "Device Manager" under "Mice and other pointing devices". I think this only happens when booting with the device plugged in. It shows the BallPoint as using COM4. However, the "Advanced Serial Port Terminal" test still works. Disabling the BallPoint doesn't fix my Rxtx program; neither does plugging the usb-serial adapter back in, which removes the BallPoint from the list. The "Advanced Serial" test works fine in all the above cases. Any other ideas? Thanks alot, Paul From tjarvi at qbang.org Tue Feb 19 18:26:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:26:24 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <1203432000.8990.0.camel@McM> References: <1203432000.8990.0.camel@McM> Message-ID: On Tue, 19 Feb 2008, Miguel wrote: > I got stack with the RXTX library and I dont understand why, > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > thrown while loading gnu.io.RXTXCommDriver > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > dont understand, > > Here is the exact line of code of the commPortIdentifier.java: > > > Sync = new Object(); > try > { > CommDriver RXTXDriver = (CommDriver) > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > RXTXDriver.initialize(); > } > catch (Throwable e) > { > System.err.println(e + " thrown while loading " + > "gnu.io.RXTXCommDriver"); > } > > could anybody please help me?? Thank you in advance > It appears you have Sun's comm.jar on your classpath and are importing javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* namespace to avoid confusion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:31:44 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:31:44 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BB0C18.9010102@cox.net> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: On Tue, 19 Feb 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> We can discuss and test different approaches but close should just close >> IMO. > > The performance changes, are interesting to me. I'd think that the latency > between bytes on a typically serial port application up to about 19,200 baud, > would be significant compared to the latency injected in the concurrency > artifacts. But, I don't have a place to examine the issues directly, so it's > great to hear of your's and others' experiences. > Hi Gregg, While the 19.2k use case is very typical, I'm starting to see use cases for ~5 Mbit/sec serial devices. I'm more than willing to share any findings but I have to do that on my own time so they may take a while. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 18:44:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 18:44:12 -0700 (MST) Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: On Tue, 19 Feb 2008, Paul Giblock wrote: > Trent - > > Thank you for the fast response. I have performed more debugging and > have some, probably sad, news. > > My development system is a dual-boot Linux-Windows configuration. So, > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > library and native binaries just in case. Rxtx enumerates the same > ports (COM3, COM4) as my other Windows software does, so this is good. > However, reading from the port still results in no data. I can > reboot into Linux and it works fine. > > I installed the program "Advanced Serial Port Terminal by Eltima > Software", a glorified terminal. If I read from the serial port > (COM4) I do, in fact, receive the first packet. If I set the software > to send ACK responses every 100ms, then I receive all of my packets. > So, it looks like the OS, BIOS, USB converter, and serial device are > all working fine. > > One thing I did notice: Sometimes Windows detects my device as a > "Microsoft Serial BallPoint". This is shown under "Device Manager" > under "Mice and other pointing devices". I think this only happens > when booting with the device plugged in. It shows the BallPoint as > using COM4. However, the "Advanced Serial Port Terminal" test still > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > does plugging the usb-serial adapter back in, which removes the > BallPoint from the list. The "Advanced Serial" test works fine in > all the above cases. > You might try adding an event listener to listen for bytes available events. Try reading when you get them. It may be that the port is just timing out. It is possible to set thresholds and timeouts to control the behavior. Try to intentionally set the port parameters to ensure something isn't wrong by default. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Feb 19 19:04:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 Feb 2008 19:04:27 -0700 (MST) Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: <47BB0814.2060102@host.sk> References: <47BB0814.2060102@host.sk> Message-ID: On Tue, 19 Feb 2008, mirek wrote: > hello > > i am newbie in 1-wire programming and at the moment i am trying to > configure my development environment for this purpose. so: > > - i am running ubuntu server 7.10 with kernel 2.6.22-14 > > - i installed the package librxtx-java which provides the 2.1.7-2 > version of rxtx > > - java -version: > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) > > - lsusb: > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 > Fob, 1-Wire adapter > Bus 002 Device 001: ID 0000:0000 > > - dmesg|grep usb > [ 27.316169] usbcore: registered new interface driver usbfs > [ 27.316247] usbcore: registered new interface driver hub > [ 27.316313] usbcore: registered new device driver usb > [ 7.700000] usb usb1: configuration #1 chosen from 1 choice > [ 7.810000] usb usb2: configuration #1 chosen from 1 choice > [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and > address 2 > [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice > [ 21.080000] usbcore: registered new interface driver DS9490R > [ 24.680000] usbcore: registered new interface driver usbserial > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > [ 24.680000] usbcore: registered new interface driver usbserial_generic > [ 24.680000] > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB > Serial Driver core > > - lsmod|grep usb > usbserial 34920 0 > usbcore 138760 4 usbserial,ds2490,uhci_hcd > > - version of onewireapi is 1.10 > > the problem is - i cannot make my ds9490r running. when i try to compile > and run application, which just shows the available adapters, the output is: > > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 > Adapter: NetAdapte > > where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info > about existence of /dev/ttyUSBx files, but there is no such file in my > /dev directory. for this purpose i loaded usbserial module, but this > doesn't help. is link from /dev/ttyS0 just enough? or the problem is > completly somewhere else? > The linux kernel looks at the major and minor numbers when a port is opened. crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 It then knows which kernel driver to talk to. If you make a link _to_ ttyS0, then the generial serial driver is used. ttyUSB uses different major and minor numbers: crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 Assuming thats the right device file for the USB dongle, the kernel would then talk to the device. I see that the driver loaded but I don't see a message that it recognized a device. It would be better if someone else talked about possible automatic device file creation that may happen when the kernel identifies a device. This may actually be the problem on your system. You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux distros or mknod(1). Once you have a device node you can create a symbolic link to it. mknod /dev/ttyUSB0 c 188 0 ln -s /dev/ttyUSB0 /dev/ttyS64 /dev/ttyS64 would then be enumerated. The name of the device node is just for your convenience. The kernel looks at the nod's attributes. -- Trent Jarvi tjarvi at qbang.org From mirek at host.sk Wed Feb 20 01:26:11 2008 From: mirek at host.sk (mirek) Date: Wed, 20 Feb 2008 09:26:11 +0100 Subject: [Rxtx] problem with ds9490r + onewireapi + rxtx + ubuntu In-Reply-To: References: <47BB0814.2060102@host.sk> Message-ID: <47BBE423.3080506@host.sk> Trent Jarvi wrote: > On Tue, 19 Feb 2008, mirek wrote: > >> hello >> >> i am newbie in 1-wire programming and at the moment i am trying to >> configure my development environment for this purpose. so: >> >> - i am running ubuntu server 7.10 with kernel 2.6.22-14 >> >> - i installed the package librxtx-java which provides the 2.1.7-2 >> version of rxtx >> >> - java -version: >> java version "1.6.0_03" >> Java(TM) SE Runtime Environment (build 1.6.0_03-b05) >> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) >> >> - lsusb: >> Bus 001 Device 001: ID 0000:0000 >> Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 >> Fob, 1-Wire adapter >> Bus 002 Device 001: ID 0000:0000 >> >> - dmesg|grep usb >> [ 27.316169] usbcore: registered new interface driver usbfs >> [ 27.316247] usbcore: registered new interface driver hub >> [ 27.316313] usbcore: registered new device driver usb >> [ 7.700000] usb usb1: configuration #1 chosen from 1 choice >> [ 7.810000] usb usb2: configuration #1 chosen from 1 choice >> [ 8.410000] usb 2-1: new full speed USB device using uhci_hcd and >> address 2 >> [ 8.580000] usb 2-1: configuration #1 chosen from 1 choice >> [ 21.080000] usbcore: registered new interface driver DS9490R >> [ 24.680000] usbcore: registered new interface driver usbserial >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial support registered for generic >> [ 24.680000] usbcore: registered new interface driver >> usbserial_generic >> [ 24.680000] >> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: >> USB >> Serial Driver core >> >> - lsmod|grep usb >> usbserial 34920 0 >> usbcore 138760 4 usbserial,ds2490,uhci_hcd >> >> - version of onewireapi is 1.10 >> >> the problem is - i cannot make my ds9490r running. when i try to compile >> and run application, which just shows the available adapters, the >> output is: >> >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 >> Adapter: NetAdapte >> >> where DS9097U is not my usb->1-wire adaptor ds9490r. i read some info >> about existence of /dev/ttyUSBx files, but there is no such file in my >> /dev directory. for this purpose i loaded usbserial module, but this >> doesn't help. is link from /dev/ttyS0 just enough? or the problem is >> completly somewhere else? >> > > The linux kernel looks at the major and minor numbers when a port is > opened. > > crw-rw---- 1 root uucp 4, 64 Feb 13 2005 /dev/ttyS0 > > It then knows which kernel driver to talk to. > > If you make a link _to_ ttyS0, then the generial serial driver is > used. ttyUSB uses different major and minor numbers: > > crw-rw---- 1 root uucp 188, 0 Feb 19 01:25 /dev/ttyUSB0 > > Assuming thats the right device file for the USB dongle, the kernel > would then talk to the device. I see that the driver loaded but I > don't see a message that it recognized a device. It would be better > if someone else talked about possible automatic device file creation > that may happen when the kernel identifies a device. This may > actually be the problem on your system. > > You can create /dev/ttyUSB0 with MAKEDEV that often comes with Linux > distros or mknod(1). Once you have a device node you can create a > symbolic link to it. > > mknod /dev/ttyUSB0 c 188 0 > ln -s /dev/ttyUSB0 /dev/ttyS64 > > /dev/ttyS64 would then be enumerated. > > The name of the device node is just for your convenience. The kernel > looks at the nod's attributes. > > -- > Trent Jarvi > tjarvi at qbang.org thanks for the response jarvi. unfortunately - this is my result: i created the new device as you suggested, so there is /dev/ttyUSB0 and /dev/ttyS64. when i run the code again, the result is the same: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Adapter: DS9097U with ports: /dev/ttyS1 /dev/ttyS0 Adapter: NetAdapter with ports: when i try to run first demo app just about the usage of default adapter, it says: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 com.dalsemi.onewire.OneWireException: Port found "/dev/ttyS1" but Adapter "DS9097U" not detected so - does this mean, that /dev/ttyS1 is the port, where is the ds9490r connected? the ds9097u is set as default adapter according to the java -jar OneWireAPI.jar, and i want to change it, but i can't, when i cannot recognize the ds9490r adapter... :-( also - the module with the name ds2490 is loaded and sometimes i am confused about the naming (i work also remotely on this computer), because - in the dmesg is message: registered new interface driver DS9490R ...but when i type lsusb, there is no mention abou ds9490r, but about ds2490: Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter this computer is also little bit old (duron 750mhz) and there is no usb2 support, but i think, this is not the problem - i am running also owfs for testing there without problems. but - the problem is somewhere else and i don't know where :-( so - if you will recommend me something else, i will appreciate your help. thanks a lot. mirek -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo formatoch .doc, .docx a .ppt (power point) precitajte si http://www.gnu.org/philosophy/no-word-attachments.cs.html From mc354 at tid.es Wed Feb 20 01:28:26 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:28:26 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496106.14108.3.camel@McM> comm.jar is not in my file system. It is really weird, and for sure I am using the last rxtx (and the gpsylon project classes to access gps which dont need comm.jar) . Actually, first I made a simple call to the method getPortIdentifiers. Here is the complete stacktrace: getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Antes java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: javax/comm/CommDriver at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java:261) at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) Experimental: JNI_OnLoad called. any other ideas? On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7cbbc659/attachment-0019.html From mc354 at tid.es Wed Feb 20 01:34:32 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 09:34:32 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> Message-ID: <1203496472.14108.6.camel@McM> I forgot to comment the development enviroment: ubuntu feisty and jvm 1.6, using the last version of the rxtx, http://www.rxtx.org On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > On Tue, 19 Feb 2008, Miguel wrote: > > > I got stack with the RXTX library and I dont understand why, > > > > the error I get: java.lang.NoClassDefFoundError: javax/comm/CommDriver > > thrown while loading gnu.io.RXTXCommDriver > > > > But It is supossed that the new library rxtx doesnt use javaxcomm ... I > > dont understand, > > > > Here is the exact line of code of the commPortIdentifier.java: > > > > > > Sync = new Object(); > > try > > { > > CommDriver RXTXDriver = (CommDriver) > > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > > RXTXDriver.initialize(); > > } > > catch (Throwable e) > > { > > System.err.println(e + " thrown while loading " + > > "gnu.io.RXTXCommDriver"); > > } > > > > could anybody please help me?? Thank you in advance > > > > It appears you have Sun's comm.jar on your classpath and are importing > javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > namespace to avoid confusion. > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/c27f5904/attachment-0019.html From netbeans at gatworks.com Wed Feb 20 04:40:47 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 20 Feb 2008 06:40:47 -0500 Subject: [Rxtx] The next release. In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> Message-ID: <47BC11BF.4080601@gatworks.com> > I'm more than willing to share any findings but I have to do that on my > own time so they may take a while. Can the original reporter of slowness in reading (or writing) single bytes ( at a time ) affirm (or suggest ) that without any synchronization calls, it took longer to accomplish? Does anyone know why IOLocked was introduced? What problem was it supposed to have resolved? From ajmas at sympatico.ca Wed Feb 20 07:29:09 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 09:29:09 -0500 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496472.14108.6.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496472.14108.6.camel@McM> Message-ID: Did you try getting the download from here: http://rxtx.qbang.org/wiki/index.php/Download The new Library uses gnu.io.*. What it sounds like is that you compiled with javax.comm and then when you ran it you didn't have the class definition around. It would appear you are mixing stuff. Try starting off with a simple project, ensuring that everything is together and that the classpath it correct. To check that you have the right JAR, you can list the contents: jar -tf RXTXcomm.jar Andre On 20-Feb-08, at 03:34 , Miguel wrote: > I forgot to comment the development enviroment: ubuntu feisty and > jvm 1.6, using the last version of the rxtx, http://www.rxtx.org > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From drvdijk at gmail.com Wed Feb 20 07:30:47 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 15:30:47 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203496106.14108.3.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: Hi. I am quite new to RXTX (this is my first mail to the mailing list), and I don't know very much about classloaders, but maybe my thoughts can help you finding the problem somehow. The ClassLoader that the CommPortIdentifier in the gnu.io package is using, tries to load the CommDriver class to cast the result of newInstance() call. Allthough the CommPortIdentifier class does not import the javax.comm package, the ClassLoader used does look for the javax.comm package. How is your classloader setup? Are you using custom classloaders? Hope it helps somehow :) Sincerely, Daan On 20 feb 2008, at 09:28, Miguel wrote: > comm.jar is not in my file system. It is really weird, and for sure > I am using the last rxtx (and the gpsylon project classes to access > gps which dont need comm.jar) . > > Actually, first I made a simple call to the method getPortIdentifiers. > > Here is the complete stacktrace: > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > CommDriver thrown while loading gnu.io.RXTXCommDriver > Antes > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: javax/comm/CommDriver > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > 261) > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > Experimental: JNI_OnLoad called. > > > any other ideas? > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: >> >> On Tue, 19 Feb 2008, Miguel wrote: >> >> > I got stack with the RXTX library and I dont understand why, >> > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ >> CommDriver >> > thrown while loading gnu.io.RXTXCommDriver >> > >> > But It is supossed that the new library rxtx doesnt use >> javaxcomm ... I >> > dont understand, >> > >> > Here is the exact line of code of the commPortIdentifier.java: >> > >> > >> > Sync = new Object(); >> > try >> > { >> > CommDriver RXTXDriver = (CommDriver) >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); >> > RXTXDriver.initialize(); >> > } >> > catch (Throwable e) >> > { >> > System.err.println(e + " thrown while loading " + >> > "gnu.io.RXTXCommDriver"); >> > } >> > >> > could anybody please help me?? Thank you in advance >> > >> >> It appears you have Sun's comm.jar on your classpath and are >> importing >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* >> namespace to avoid confusion. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mc354 at tid.es Wed Feb 20 08:45:40 2008 From: mc354 at tid.es (Miguel) Date: Wed, 20 Feb 2008 16:45:40 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> Message-ID: <1203522340.14108.23.camel@McM> Thank you very much for your help, it s driving me crazy :-s - I m using the last version of RXTXComm.jar, downloaded from both wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official page (www.rxtx.org) . - the loader is the normal one, no customization Actually, the header of the decompiled CommPortIdentifier.java is: -------------------------------- // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Name: CommPortIdentifier.java package gnu.io; import java.io.FileDescriptor; import java.io.PrintStream; import java.util.Enumeration; import java.util.Vector; public class CommPortIdentifier { [...] ---------------------------------------- - there's no comm.jar, neither the classpath nor the file system. - I 'm using java 6, and I run my client from eclipse enviroment although I have tried to do it by using the command line: mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/gps_client/lib/native/ Client ----------------------- getportIdentifiers .... java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver Experimental: JNI_OnLoad called. java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not available. at org.dinopolis.gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) at org.dinopolis.gpstool.gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java:163) at Client.main(Client.java:41) ----------------------------------- I'm working under linux os, any ideas? best regards, Miguel On Wed, 2008-02-20 at 15:30 +0100, Daan van Dijk wrote: > Hi. I am quite new to RXTX (this is my first mail to the mailing > list), and I don't know very much about classloaders, but maybe my > thoughts can help you finding the problem somehow. > > The ClassLoader that the CommPortIdentifier in the gnu.io package is > using, tries to load the CommDriver class to cast the result of > newInstance() call. Allthough the CommPortIdentifier class does not > import the javax.comm package, the ClassLoader used does look for the > javax.comm package. How is your classloader setup? Are you using > custom classloaders? > > Hope it helps somehow :) Sincerely, Daan > > > On 20 feb 2008, at 09:28, Miguel wrote: > > > comm.jar is not in my file system. It is really weird, and for sure > > I am using the last rxtx (and the gpsylon project classes to access > > gps which dont need comm.jar) . > > > > Actually, first I made a simple call to the method getPortIdentifiers. > > > > Here is the complete stacktrace: > > > > getportIdentifiers ....java.lang.NoClassDefFoundError: javax/comm/ > > CommDriver thrown while loading gnu.io.RXTXCommDriver > > Antes > > > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > > loading gnu.io.RXTXCommDriver > > java.lang.NoClassDefFoundError: javax/comm/CommDriver > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > > 124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:169) > > at > > gnu.io.CommPortIdentifier.getPortIdentifiers(CommPortIdentifier.java: > > 261) > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:117) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > > available. > > at > > org > > .dinopolis > > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > > at > > org > > .dinopolis > > .gpstool > > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > > 163) > > at Client.main(Client.java:41) > > Experimental: JNI_OnLoad called. > > > > > > any other ideas? > > > > > > On Tue, 2008-02-19 at 18:26 -0700, Trent Jarvi wrote: > >> > >> On Tue, 19 Feb 2008, Miguel wrote: > >> > >> > I got stack with the RXTX library and I dont understand why, > >> > > >> > the error I get: java.lang.NoClassDefFoundError: javax/comm/ > >> CommDriver > >> > thrown while loading gnu.io.RXTXCommDriver > >> > > >> > But It is supossed that the new library rxtx doesnt use > >> javaxcomm ... I > >> > dont understand, > >> > > >> > Here is the exact line of code of the commPortIdentifier.java: > >> > > >> > > >> > Sync = new Object(); > >> > try > >> > { > >> > CommDriver RXTXDriver = (CommDriver) > >> > Class.forName("gnu.io.RXTXCommDriver").newInstance(); > >> > RXTXDriver.initialize(); > >> > } > >> > catch (Throwable e) > >> > { > >> > System.err.println(e + " thrown while loading " + > >> > "gnu.io.RXTXCommDriver"); > >> > } > >> > > >> > could anybody please help me?? Thank you in advance > >> > > >> > >> It appears you have Sun's comm.jar on your classpath and are > >> importing > >> javax.comm.* in your application. rxtx 2.1 resides in the gnu.io.* > >> namespace to avoid confusion. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/8030e8c0/attachment-0018.html From ajmas at sympatico.ca Wed Feb 20 09:13:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:13:49 -0500 Subject: [Rxtx] CVS, directory structure etc Message-ID: <6bpki0$7v15vt@toip3.srvr.bell.ca> Hi, I have a few questions: - Why is the 'deprecated' javax.comm line on the HEAD, instead of the maintained gnu.io branch in CVS? - Is there any reason why the Java source in the commapi-0-0-1 flat, instead of being organised into packages? Andre From ajmas at sympatico.ca Wed Feb 20 09:24:45 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 11:24:45 -0500 Subject: [Rxtx] Logging Message-ID: <6bpki0$7v17tg@toip3.srvr.bell.ca> Hi, I noticed that there are some debug outputs in the Java source of rxtx. If we finally decide to make the move to requiring JDK 1.5, I would be tempted to use a proper logger for these messages. Two options include the one included by the JDK, or log4j. Each have their relative merits and I would be curious to know whether there would be any preferences and whether this would be something that would be of interest. Andre From bschlining at gmail.com Wed Feb 20 09:45:30 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 08:45:30 -0800 Subject: [Rxtx] Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: > I noticed that there are some debug outputs in the Java source of rxtx. If > we finally decide to make the move to requiring JDK 1.5, I would be > tempted to use a proper logger for these messages. Two options include the > one included by the JDK, or log4j. Each have their relative merits and I > would be curious to know whether there would be any preferences and whether > this would be something that would be of interest. I would much prefer RXTX used a pluggable logging facade like SLF4J (See http://www.slf4j.org/). You write the code using the facade, then plug in your logger of choice at run time. Supported loggers include log4j, commons-logging, jdk-logging, NOP and a simple logger. It's pretty easy to add other loggers too. The advantage is it allows the applications developer to use whatever logger they prefer and not be stuck with what the library designer used. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/faf2c916/attachment-0018.html From drvdijk at gmail.com Wed Feb 20 11:11:25 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 19:11:25 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <1203522340.14108.23.camel@McM> References: <1203432000.8990.0.camel@McM> <1203496106.14108.3.camel@McM> <1203522340.14108.23.camel@McM> Message-ID: I created a quick project with a test class in Eclipse, on Mac OS X (Java 1.5, weird Apples): package test; import java.util.Enumeration; import gnu.io.CommPortIdentifier; public class Testing { public static void main (String [] args) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port = (CommPortIdentifier) ports.nextElement(); System.out.println(port.getName()); } } } The RXTXcomm.jar as you mentioned (from http://rxtx.qbang.org/wiki/index.php/Download) is available in the project, and added to the build path. I ran it, and got the (obvious) error: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at test.Testing.main(Testing.java:11) Right, the librxtxSerial.jnilib is not installed. So, I copied that file to the root of the project (the Test.java being in / src/test/Test.java , the librxtxSerial.jnilib in / librxtxSerial.jnilib), and ran it again: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.AD850-BluetoothSerialPo-1 /dev/cu.AD850-BluetoothSerialPo-1 ..... Is the librxtxSerial.jnilib available? Cheers, Daan On 20 feb 2008, at 16:45, Miguel wrote: > Thank you very much for your help, > > it s driving me crazy :-s > > - I m using the last version of RXTXComm.jar, downloaded from both > wiki (http://rxtx.qbang.org/wiki/index.php/Download) and official > page (www.rxtx.org) . > > - the loader is the normal one, no customization > > Actually, the header of the decompiled CommPortIdentifier.java is: > > -------------------------------- > // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. > // Jad home page: http://www.geocities.com/kpdus/jad.html > // Decompiler options: packimports(3) > // Source File Name: CommPortIdentifier.java > > package gnu.io; > > import java.io.FileDescriptor; > import java.io.PrintStream; > import java.util.Enumeration; > import java.util.Vector; > > public class CommPortIdentifier > { > > [...] > ---------------------------------------- > > > - there's no comm.jar, neither the classpath nor the file system. > > - I 'm using java 6, and I run my client from eclipse enviroment > although I have tried to do it by using the command line: > > mcm at McM:~/gps_client$ /usr/lib/jvm/java-6-sun/bin/java -cp .:lib/ > java/RXTXcomm.jar:lib/gpsinput-0.5.3.jar:lib/gpstool-0.5.3.jar:lib/ > log4j-1.2.14.jar -Djava.library.path=/home/mcm/ecar_mejorado/ > gps_client/lib/native/ Client > > ----------------------- > getportIdentifiers .... > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > Experimental: JNI_OnLoad called. > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > org.dinopolis.gpstool.gpsinput.GPSException: port '/dev/ttyACM0' not > available. > at > org > .dinopolis > .gpstool.gpsinput.GPSSerialDevice.open(GPSSerialDevice.java:136) > at > org > .dinopolis > .gpstool > .gpsinput.nmea.GPSNmeaDataProcessor.open(GPSNmeaDataProcessor.java: > 163) > at Client.main(Client.java:41) > > ----------------------------------- > > I'm working under linux os, > > any ideas? > > best regards, > > Miguel From g.telkamp at domologic.de Wed Feb 20 11:28:04 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Wed, 20 Feb 2008 19:28:04 +0100 Subject: [Rxtx] Problems closing a port asynchronously Message-ID: <47BC7134.5020804@domologic.de> We have noticed a strange behaviour of the RXTX library when we close a serial port _asynchronously_ by an independant thread. Then, the JVM crashes, we get endless loops in the RXTX DLLs, and other nice things. In our application, we are using this thread to close the serial port automatically after 2 sec. This is an optional "optimization feature" in our application, keeping the port open in case that we need it again within a short time. When the port is used again, the closing thread is interrupted and it is started again after the port is not needed anymore. It seems that the crashes are caused by the application, using another port (e.g. COM3), when the closing thread comes, closing a port that is not nedded anymore (e.g. COM1). Ok, I know that it would be the easiest to skip this feature and to close the port _directly_ when we do not need it anymore, like most applications do. Hence, the problem is not critical for us, but I think the reason is a general problem of the RXTX library and I would like to know if also other users have noticed a similar behaviour. I suppose that it could be solved easily in the code when "critical" RXTX methods (like close()) are declared as "synchronized". What do you think? What is very funny is that the old javax.comm library works with our application... BR, Gerrit. From ajmas at sympatico.ca Wed Feb 20 11:32:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 13:32:10 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Daan van Dijk wrote > > I ran it, and got the (obvious) error: > > java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path > thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > rxtxSerial in java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) > at java.lang.Runtime.loadLibrary0(Runtime.java:822) > at java.lang.System.loadLibrary(System.java:993) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at test.Testing.main(Testing.java:11) This means that the jnilib is missing form you environment. For a basic project this should be placed in the launch directory of the application. Since you are saying you are using Eclipse, the launch directory is your project directory. Andre From beat.arnet at gmail.com Wed Feb 20 11:56:21 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 20 Feb 2008 13:56:21 -0500 Subject: [Rxtx] Problems closing a port asynchronously In-Reply-To: <47BC7134.5020804@domologic.de> References: <47BC7134.5020804@domologic.de> Message-ID: Hi Gerrit. I recommend that you search the list for "Dual Core Problem". Cheers, Beat On Feb 20, 2008 1:28 PM, Gerrit Telkamp wrote: > We have noticed a strange behaviour of the RXTX library when we close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing thread is > interrupted and it is started again after the port is not needed anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I think > the reason is a general problem of the RXTX library and I would like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > 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/20080220/02b859c9/attachment-0018.html From drvdijk at gmail.com Wed Feb 20 12:04:38 2008 From: drvdijk at gmail.com (Daan van Dijk) Date: Wed, 20 Feb 2008 20:04:38 +0100 Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v1t8m@toip3.srvr.bell.ca> References: <6bpki0$7v1t8m@toip3.srvr.bell.ca> Message-ID: <560B7342-E78A-470F-8015-623A1670F0A7@gmail.com> Exactly. That is what I was suggesting Miguel: On 20 feb 2008, at 19:11, Daan van Dijk wrote: > Right, the librxtxSerial.jnilib is not installed. So, I copied that > file to the root of the project (the Test.java being in > /src/test/Test.java , the librxtxSerial.jnilib in > /librxtxSerial.jnilib) [...] Might this problem also explain his errors with the ClassLoader used in the CommPortIdentifier class trying to load a javax.comm.CommDriver while it should try to load a gnu.io.CommDriver ? Cheers, Daan On 20 feb 2008, at 19:32, Andre-John Mas wrote: > Daan van Dijk wrote >> >> I ran it, and got the (obvious) error: >> >> java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path >> thrown while loading gnu.io.RXTXCommDriver >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no >> rxtxSerial in java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753) >> at java.lang.Runtime.loadLibrary0(Runtime.java:822) >> at java.lang.System.loadLibrary(System.java:993) >> at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) >> at test.Testing.main(Testing.java:11) > > This means that the jnilib is missing form you environment. For a > basic project this should be placed in the launch directory of the > application. Since you are saying you are using Eclipse, the launch > directory is your project directory. > > Andre > From ajmas at sympatico.ca Wed Feb 20 13:11:49 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Feb 2008 15:11:49 -0500 Subject: [Rxtx] rxtx problem Message-ID: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Daan van Dijk wrote > > Exactly. That is what I was suggesting Miguel: > > On 20 feb 2008, at 19:11, Daan van Dijk wrote: > > Right, the librxtxSerial.jnilib is not installed. So, I copied that > > file to the root of the project (the Test.java being in > > /src/test/Test.java , the librxtxSerial.jnilib in > > /librxtxSerial.jnilib) [...] > > Might this problem also explain his errors with the ClassLoader used > in the CommPortIdentifier class trying to load a javax.comm.CommDriver > while it should try to load a gnu.io.CommDriver ? > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. Andre From bschlining at gmail.com Wed Feb 20 15:07:29 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 14:07:29 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: My vote goes to log4j - simple, small and gets the job done. > Unless the rest of your application uses a different logging API. Then you're forced to track 2 different logs, logging configuration, etc. Just because you prefer log4j doesn't mean that everyone else does. Software library's shouldn't cram a logging API down an applications developers throat. Using a logging facade gives the application developer much more flexibility to use log4j at runtime/test-time if they want. Or plugin a different one if you need it. There are 2 popular facades, SLF4J (which I would recommend) and Apache's commons-logging (less recommended). They're both very simple to use and the API's will feel very familiar to log4j users. As an example: to use log4j with SLF4J, you simply put the jar file containing the slf4j-log4j.jar on the classpath, add your log4j config file and that's it. If someone else wants to use jdk logging with it, they just put slf4j-jdk.jar on the classpath. It may be worthwhile to point out some other Java projects that use logging facades, such as ALL the apache java projects, Hibernate, and Spring. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/a8a82962/attachment-0018.html From vt at freehold.crocodile.org Wed Feb 20 15:42:23 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 15:42:23 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. Just > because you prefer log4j doesn't mean that everyone else does. Fair enough. Except for the fact that log4j can be configured with adapters (actually, appenders) to any other logging system, and there's plenty of them available already. The opposite is also true - other logging systems can use log4j appenders as output media. > As an example: to use log4j with SLF4J, you simply put the jar file > containing the slf4j-log4j.jar on the classpath, add your log4j config file > and that's it. If someone else wants to use jdk logging with it, they just > put slf4j-jdk.jar on the classpath. So in other words, we end up with having TWO (at least) sets of loggers instead of one. And this is given the fact of high likelihood of applications using RxTx working in CPU and memory constrained environments. > It may be worthwhile to point out some other Java projects that use logging > facades, such as ALL the apache java projects, Hibernate, and Spring. Doesn't impress me at all. Give me one good reason they can't use one logging system (this *is* a rhetorical question). There's this beautiful principle of "worse is better" (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good reading for Jakarta projects' contributors. Does a facade offer functionality that RxTx (or any other project mentioned above, for that matter) absolutely can't live without? (this is *not* a rhetorical question). Another reason - "voting with your dollars". The more applications use *one* solution (granted, maybe somewhat lacking, though definitely not in this particular case), the more motivation there is to improve that one specific solution, instead of scattering efforts. Another reason - low level solution (RxTx) doesn't have to depend on higher level solution (facades). Jakarta projects exhibit strong tendency to bloat and lose stability over time. I don't want to be debugging loggers - RxTx gives me its fair share of troubles already. Again, just my $0.02. > Brian Schlining --vt From tjarvi at qbang.org Wed Feb 20 17:23:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:23:21 -0700 (MST) Subject: [Rxtx] rxtx problem In-Reply-To: <6bpki0$7v2cqp@toip3.srvr.bell.ca> References: <6bpki0$7v2cqp@toip3.srvr.bell.ca> Message-ID: On Wed, 20 Feb 2008, Andre-John Mas wrote: > Daan van Dijk wrote >> >> Exactly. That is what I was suggesting Miguel: >> >> On 20 feb 2008, at 19:11, Daan van Dijk wrote: >>> Right, the librxtxSerial.jnilib is not installed. So, I copied that >>> file to the root of the project (the Test.java being in >>> /src/test/Test.java , the librxtxSerial.jnilib in >>> /librxtxSerial.jnilib) [...] >> >> Might this problem also explain his errors with the ClassLoader used >> in the CommPortIdentifier class trying to load a javax.comm.CommDriver >> while it should try to load a gnu.io.CommDriver ? >> > > I doubt it. This sounds more like the original code he had written was importing the javax.comm definitions and then failing because the runtime was different. Gnu.io makes no reference to javax.comm. > He has the wrong import. Perhaps because he used rxtx 2.0 with Sun's CommAPI in the past. If he upgraded to 2.1, that would explain why the class is not found. We moved rxtx out of the javax.comm namespace in 2.1 to avoid spoiling Sun's namespace by accident. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Feb 20 17:28:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Feb 2008 17:28:27 -0700 (MST) Subject: [Rxtx] The next release. In-Reply-To: <47BC11BF.4080601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584804769DBA@ism-mail03.corp.ad.wrs.com> <47B4B1B3.1040704@cox.net> <47B50B08.8040606@gatworks.com> <47B9D5E7.2000800@cox.net> <47BB0C18.9010102@cox.net> <47BC11BF.4080601@gatworks.com> Message-ID: On Wed, 20 Feb 2008, U. George wrote: >> I'm more than willing to share any findings but I have to do that on my >> own time so they may take a while. > > Can the original reporter of slowness in reading (or writing) single > bytes ( at a time ) affirm (or suggest ) that without any > synchronization calls, it took longer to accomplish? > > Does anyone know why IOLocked was introduced? What problem was it > supposed to have resolved? IOLocked was introduced so that the eventLoop could shut down gracefully. If we can make that loop more robust, we can probably do away with the IOLocking. -- Trent Jarvi tjarvi at qbang.org From drfaygo at gmail.com Wed Feb 20 18:19:17 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 20 Feb 2008 20:19:17 -0500 Subject: [Rxtx] Windows Borkage - missing ports and broken reads In-Reply-To: References: <748d0ca90802191012t6e20e110j85f4f7651253ced9@mail.gmail.com> Message-ID: <748d0ca90802201719s25744b0ag21965413359d603c@mail.gmail.com> I solved the problem, by a matter of luck actually. Trent recommended that I test with an eventListener to see if the outcome is any different in Windows. Naturally, I look online for some example code so I can test the the listening approach quickly. I saw, in the example code, the author used: SerialPort.setDTR() and setRTS(). I know my device doesn't have a DTR wire so I added the following to my code: serialPort.setDTR(false); serialPort.setRTS(true); and guess what? It works in Windows now. Even the simple looping version. This raises the question: do the different native binaries assume different default values? If so, this is something that could be fixed to make the library more portable, or at least more consistent. I haven't looked at the native C code yet, and I figured someone may know offhand. If not, I may try to take a look. Thanks again! Paul On Tue, Feb 19, 2008 at 8:44 PM, Trent Jarvi wrote: > > On Tue, 19 Feb 2008, Paul Giblock wrote: > > > Trent - > > > > Thank you for the fast response. I have performed more debugging and > > have some, probably sad, news. > > > > My development system is a dual-boot Linux-Windows configuration. So, > > I installed Eclipse in Windows. I downloaded the 2.1-7 final stable > > library and native binaries just in case. Rxtx enumerates the same > > ports (COM3, COM4) as my other Windows software does, so this is good. > > However, reading from the port still results in no data. I can > > reboot into Linux and it works fine. > > > > I installed the program "Advanced Serial Port Terminal by Eltima > > Software", a glorified terminal. If I read from the serial port > > (COM4) I do, in fact, receive the first packet. If I set the software > > to send ACK responses every 100ms, then I receive all of my packets. > > So, it looks like the OS, BIOS, USB converter, and serial device are > > all working fine. > > > > One thing I did notice: Sometimes Windows detects my device as a > > "Microsoft Serial BallPoint". This is shown under "Device Manager" > > under "Mice and other pointing devices". I think this only happens > > when booting with the device plugged in. It shows the BallPoint as > > using COM4. However, the "Advanced Serial Port Terminal" test still > > works. Disabling the BallPoint doesn't fix my Rxtx program; neither > > does plugging the usb-serial adapter back in, which removes the > > BallPoint from the list. The "Advanced Serial" test works fine in > > all the above cases. > > > > You might try adding an event listener to listen for bytes available > events. Try reading when you get them. > > It may be that the port is just timing out. It is possible to set > thresholds and timeouts to control the behavior. Try to intentionally set > the port parameters to ensure something isn't wrong by default. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From bschlining at gmail.com Wed Feb 20 21:26:24 2008 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 20 Feb 2008 20:26:24 -0800 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: Vlad, What the heck are you talking about? You're spouting a lot of nonsense and blog-o-sphere based opinions. When the rubber meets the road, there's only 2 things that need to be kept in mind: 1) Performance impact of the logging solution on RXTX. 2) Usability by the application developer (not the RXTX library developer) Trent and Andre, As a heavy user of RXTX in applications, I would prefer to be able to plug in my logging system of choice at runtime. Anyway, 'nuff said about this. Sheesh. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080220/7da3018d/attachment-0018.html From vt at freehold.crocodile.org Wed Feb 20 22:05:21 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 20 Feb 2008 22:05:21 -0700 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <2251ead40802202105u7c5c651an5c3695a0124237e3@mail.gmail.com> On 2/20/08, Brian Schlining wrote: > > Vlad, > > What the heck are you talking about? You're spouting a lot of nonsense and > blog-o-sphere based opinions. Feel free to conduct independent analysis of depth of my involvement with logging systems - Google is your friend. > Brian Schlining --vt From mc354 at tid.es Thu Feb 21 01:50:06 2008 From: mc354 at tid.es (Miguel) Date: Thu, 21 Feb 2008 09:50:06 +0100 Subject: [Rxtx] [Fwd: Re: rxtx problem] Message-ID: <1203583806.14108.41.camel@McM> I dont know if you got the message, I sent it using other mail adress. I forward it in case you didnt get it.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0018.html -------------- next part -------------- An embedded message was scrubbed... From: Miguel Subject: Re: [Rxtx] rxtx problem Date: Thu, 21 Feb 2008 00:12:44 +0100 Size: 14916 Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080221/14ddd43e/attachment-0018.mht From Steffen.DETTMER at ingenico.com Thu Feb 21 03:15:19 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 21 Feb 2008 11:15:19 +0100 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <2251ead40802201442o367944d3p14574596936f091b@mail.gmail.com> Message-ID: <20080221101518.GC29870@elberon.bln.de.ingenico.com> * Vadim Tkachenko wrote on Wed, Feb 20, 2008 at 15:42 -0700: > > It may be worthwhile to point out some other Java projects that use logging > > facades, such as ALL the apache java projects, Hibernate, and Spring. > > Doesn't impress me at all. Give me one good reason they can't use one > logging system (this *is* a rhetorical question). There's this > beautiful principle of "worse is better" > (http://en.wikipedia.org/wiki/Worse_is_better) - would be a good > reading for Jakarta projects' contributors. :-) Yes, I think when talking about java.util.logging or complexer, it won't be simple. Actually, logging is not simple I think :) Sometimes, when some subsystem just wants to publish some messages, maybe an interface just to publish messages is sufficient (be it used for logging or not, who cares) and in this case suited. I also see advantages of java.util.logging because it is part of JDK. No need to search, download, maintain, update megabytes of jar files IMHO is an advantage. About your question, I think they cannot use one logging system, because all logging systems suck... SCNR. oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sngeza at gmail.com Thu Feb 21 03:37:43 2008 From: sngeza at gmail.com (=?ISO-8859-1?Q?Simon_G=E9za?=) Date: Thu, 21 Feb 2008 11:37:43 +0100 Subject: [Rxtx] i need a debug version for rxtx w32 dll's Message-ID: <033160F7-272E-4771-85AE-50EF3D14B48E@gmail.com> hi, having left behind C/C++/LD in 95, and never even developed on windows, I'm in a bit of a trouble. Short version: please someone build the rxtx DLL's for win32, with #define DEBUG, and give them to me. Long version: We're using RXTX from our Java code. When talking to certain devices, through certain adapters (4-way serial PCI card, usb2serial, etc), on certain windows boxes (whatever our clients have), sometimes messages just don't go out to the physical device. No exceptions, nothing. The same hardware, same java code work on a different windows box, also if I boot linux on the same PC. Also from windows, minicom and other native windows software do access the device, but our java through rxtx win32 doesn't. (our client tries minicom, so they're convinced that our program is faulty, but _exactly_ the same hardware/sw setup works on our test windows) Looking at the C code, I see most messages are commented out, unless DEBUG is defined. Now I spent 10+ hours installing windows in vmware, installing mingw32 (also tried with cygwin), doing ./configure - so far so good, and make. Make fails with various reasons. Some command line options I already moved, gcc seems to do fine, ld however still fails. I'm stuck. And frankly, I don't really want to understand all the depths. All I need is the debug libraries, to see what's happening. thanks Geza PS: oh yes, it needs to be done yesterday From gergg at cox.net Thu Feb 21 09:02:59 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 21 Feb 2008 10:02:59 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> Message-ID: <47BDA0B3.6090001@cox.net> Brian Schlining wrote: > My vote goes to log4j - simple, small and gets the job done. > > Unless the rest of your application uses a different logging API. Then > you're forced to track 2 different logs, logging configuration, etc. > Just because you prefer log4j doesn't mean that everyone else does. > > Software library's shouldn't cram a logging API down an applications > developers throat. Using a logging facade gives the > application developer much more flexibility to use log4j at > runtime/test-time if they want. Or plugin a different one if you need it. I'm really confused about why people don't think that java.util.logging is a framework. You can simply provide a Formatter and Handler that works the way you need to, and you can do that from the configuration file, without changing the code which is using it. My first consideration on using something is how many more jars am I going to have to distribute/manage. Using stuff out of the JDK is always the first choice from my perspective. Commons logging use is declining in favor of the JDK, I thought I had read... Gregg Wonderly From ajmas at sympatico.ca Thu Feb 21 17:43:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 21 Feb 2008 19:43:36 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BDA0B3.6090001@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: On 21-Feb-08, at 11:02 , Gregg Wonderly wrote: > Brian Schlining wrote: >> My vote goes to log4j - simple, small and gets the job done. >> >> Unless the rest of your application uses a different logging API. >> Then >> you're forced to track 2 different logs, logging configuration, etc. >> Just because you prefer log4j doesn't mean that everyone else does. >> >> Software library's shouldn't cram a logging API down an applications >> developers throat. Using a logging facade gives the >> application developer much more flexibility to use log4j at >> runtime/test-time if they want. Or plugin a different one if you >> need it. > > I'm really confused about why people don't think that > java.util.logging is a > framework. You can simply provide a Formatter and Handler that > works the way > you need to, and you can do that from the configuration file, > without changing > the code which is using it. > > My first consideration on using something is how many more jars am I > going to > have to distribute/manage. Using stuff out of the JDK is always the > first > choice from my perspective. > > Commons logging use is declining in favor of the JDK, I thought I > had read... At the moment nothing is planned, and if this would be done it have to be with Trent's consent. At this point, I am thinking of what could be improved in the code if we finally make the move, and this was just one of the things. I haven't used the JDK's logging mechanism much myself, since most of the projects I have been working on were already using log4j. Avoiding extra dependencies is certainly something to be taken into account, and this certainly makes the use of the JDK's logging system appealing. It should be noted that we are just speaking basic debug logging, so the chances are most people won't ever think about over-riding the default setting, to turn it on. Andre From g.telkamp at domologic.de Fri Feb 22 01:03:25 2008 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Fri, 22 Feb 2008 09:03:25 +0100 Subject: [Rxtx] Problems closing a port asynchronously] Message-ID: <47BE81CD.70308@domologic.de> Hi Beat, thank you for the info! I'm not sure if we have the same problem. But we have written a simple test application, crashing under windows after a certain time - on single & dual core cpus. I attach this application for those who are interested. We have found a work around for our application, so we can live with it. BR Gerrit. Beat Arnet schrieb: > Hi Gerrit. I recommend that you search the list for "Dual Core Problem". > Cheers, > Beat > > On Feb 20, 2008 1:28 PM, Gerrit Telkamp > wrote: > > We have noticed a strange behaviour of the RXTX library when we > close a > serial port _asynchronously_ by an independant thread. Then, the JVM > crashes, we get endless loops in the RXTX DLLs, and other nice things. > > In our application, we are using this thread to close the serial port > automatically after 2 sec. This is an optional "optimization > feature" in > our application, keeping the port open in case that we need it again > within a short time. When the port is used again, the closing > thread is > interrupted and it is started again after the port is not needed > anymore. > > It seems that the crashes are caused by the application, using another > port (e.g. COM3), when the closing thread comes, closing a port > that is > not nedded anymore (e.g. COM1). > > Ok, I know that it would be the easiest to skip this feature and to > close the port _directly_ when we do not need it anymore, like most > applications do. Hence, the problem is not critical for us, but I > think > the reason is a general problem of the RXTX library and I would > like to > know if also other users have noticed a similar behaviour. I suppose > that it could be solved easily in the code when "critical" RXTX > methods > (like close()) are declared as "synchronized". > What do you think? > > What is very funny is that the old javax.comm library works with our > application... > > BR, > Gerrit. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RS232PortTest.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080222/2fe14581/attachment-0017.pl From netbeans at gatworks.com Fri Feb 22 05:24:54 2008 From: netbeans at gatworks.com (U. George) Date: Fri, 22 Feb 2008 07:24:54 -0500 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> Message-ID: <47BEBF16.7060103@gatworks.com> can the logging facility be removed without recompiling rxtx? Or do you always have to have the logging hooks available? > I haven't used the JDK's logging mechanism much myself, since most of > the > projects I have been working on were already using log4j. Avoiding extra > dependencies is certainly something to be taken into account, and this > certainly makes the use of the JDK's logging system appealing. From michael.erskine at ketech.com Fri Feb 22 06:40:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 22 Feb 2008 13:40:42 +0000 Subject: [Rxtx] Logging In-Reply-To: <6bpki0$7v17tg@toip3.srvr.bell.ca> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> Message-ID: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Let's not forget the Zystem logging system already in rxtx! From tjarvi at qbang.org Fri Feb 22 19:39:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Feb 2008 19:39:50 -0700 (MST) Subject: [Rxtx] Logging In-Reply-To: <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <06BA3262D918014F9183B66425D5A8D425240B81A4@no-sv-03.ketech.local> Message-ID: On Fri, 22 Feb 2008, Michael Erskine wrote: > Let's not forget the Zystem logging system already in rxtx! Maybe they do know but are kind enough not to to admit it. :) Zystem may offer the place to hook in and use a system property to determine what is used. I suspect people want something more than the following though: else if (mode == J2SE_LOG_MODE) { java.util.logging.Logger.getLogger("javax.comm").fine (s); return (true); } Zystem was handy for dumping information over the network. I used some of python's native code to do that at the time and never put it into rxtx (different license). The main problem is solved for me was getting quick diagnostic information in an environment that didnt have stdout. I never found the other options useful but I guess some people do use them. I'm not attached to the code. If there is agreement on another mechanism, I'd be OK with it. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Feb 25 17:13:31 2008 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Feb 2008 18:13:31 -0600 Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47BEBF16.7060103@gatworks.com> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> Message-ID: <47C359AB.2010009@cox.net> Here is a template of using java.util.logging directly. If you really want to be able to take the logging out, because the java.util.logging package classes don't exist, then you really need to provide a logging abstraction which uses a factory model or some such to get the appropriate "instance" of implementation. Java has no #ifdef facilities built in, so conditionally removing source code from view of the compiler is not a typical thing to do... Gregg Wonderly ------------------------------------------------------------ public class MyClass { // Initialization of logger outside of constructor, might // need to do this in constructor if constructor does // logging. Logger instances are not serializable so making // it transient helps if this class or subclass might be // serializable. private transient Logger log = Logger.getLogger( getClass().getName() ); // For serializable objects, readObject needs to reconsitute the logger // since it is not serializable. private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { log = Logger.getLogger( getClass().getName() ); } // Use of logger in methods public void somefunc(... ) { // Conditionally do logging so that the work of // constructing the log message and running the // Formatter is not done if we will not log the message. // It still might not be logged in Handler level forbids it. if( log.isLoggable( Level.FINE ) ) { log.fine("doing something..."); } } } Gregg Wonderly U. George wrote: > can the logging facility be removed without recompiling rxtx? Or do you > always have to have the logging hooks available? > > > >> I haven't used the JDK's logging mechanism much myself, since most of >> the >> projects I have been working on were already using log4j. Avoiding extra >> dependencies is certainly something to be taken into account, and this >> certainly makes the use of the JDK's logging system appealing. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Feb 25 18:28:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Feb 2008 18:28:53 -0700 (MST) Subject: [Rxtx] Fwd: Fwd: Logging In-Reply-To: <47C359AB.2010009@cox.net> References: <6bpki0$7v17tg@toip3.srvr.bell.ca> <2251ead40802200945s37b69d34g1d37d2425856fcd2@mail.gmail.com> <47BDA0B3.6090001@cox.net> <47BEBF16.7060103@gatworks.com> <47C359AB.2010009@cox.net> Message-ID: Hmmm. This fits what Zystem.java does now. The logging is done via z.report..(). Perhaps it is flexible enough to allow the various loggers to work if the java is uncommented for their logging mechanism. But what I sense people want (perhaps out of frustration) is to log the native messages. On Mon, 25 Feb 2008, Gregg Wonderly wrote: > Here is a template of using java.util.logging directly. If you really want to > be able to take the logging out, because the java.util.logging package classes > don't exist, then you really need to provide a logging abstraction which uses a > factory model or some such to get the appropriate "instance" of implementation. > > Java has no #ifdef facilities built in, so conditionally removing source code > from view of the compiler is not a typical thing to do... > > Gregg Wonderly > > ------------------------------------------------------------ > public class MyClass { > // Initialization of logger outside of constructor, might > // need to do this in constructor if constructor does > // logging. Logger instances are not serializable so making > // it transient helps if this class or subclass might be > // serializable. > private transient Logger log = Logger.getLogger( getClass().getName() ); > > // For serializable objects, readObject needs to reconsitute the logger > // since it is not serializable. > private void readObject( ObjectInputStream is ) > throws IOException, ClassNotFoundException { > log = Logger.getLogger( getClass().getName() ); > } > > // Use of logger in methods > public void somefunc(... ) { > // Conditionally do logging so that the work of > // constructing the log message and running the > // Formatter is not done if we will not log the message. > // It still might not be logged in Handler level forbids it. > if( log.isLoggable( Level.FINE ) ) { > log.fine("doing something..."); > } > } > } > > Gregg Wonderly > > > U. George wrote: >> can the logging facility be removed without recompiling rxtx? Or do you >> always have to have the logging hooks available? >> >> >> >>> I haven't used the JDK's logging mechanism much myself, since most of >>> the >>> projects I have been working on were already using log4j. Avoiding extra >>> dependencies is certainly something to be taken into account, and this >>> certainly makes the use of the JDK's logging system appealing. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joao.mr.cardoso at gmail.com Tue Feb 26 04:48:29 2008 From: joao.mr.cardoso at gmail.com (Joao Cardoso) Date: Tue, 26 Feb 2008 12:48:29 +0100 Subject: [Rxtx] RXTX install on OpenSuse 10.2 Message-ID: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Hi there I'm a newbie with problems... installing RXTX in opensuse 10.2 I tried to install acconding to the instructions but I'm not quite sure of where to put the RXTXComm.jar and lib files on my system. Also I inttend to use Netbeans for testing the examples on the wiki Could you please give some hints on this? Thanx JC From doedeloe at web.de Tue Feb 26 06:54:22 2008 From: doedeloe at web.de (Iske Hetterich) Date: Tue, 26 Feb 2008 14:54:22 +0100 Subject: [Rxtx] exception access violation error References: <4d39a8fe0802260348y49b8f70epc3bf00791bd26ebb@mail.gmail.com> Message-ID: <004d01c8787f$17f1c740$0400a8c0@iske> Hello everyone, I am using RXTX 2.1-7 to connect my computer with a mobile phone through a bluetooth serial port I created on the phone. I can connect to the port using Hyperterminal just fine, I can also connect with my java program to the port which the phone creates itself. However when I try using my java program to connect to the other port, I get following output. I compiled on compliance levels of jdk 1.3, 1.4 and 6.0 with no difference in the error. Unfortunately I am quite new to this and I have little idea to what the error is, but the program itself is rather basic and it clearly occurs in the line: commPort = portIdentifier.open(this.getClass().getName(),20000). If you could read through it and see if this might be a bug within RXTX I would be very grateful. Any suggestions how to fix this are welcome. Thank you in advance Iske Console output: Java lib Version = RXTX-2.1-7 gnu.io.CommPortIdentifier at 69b332 # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=3372, tid=3508 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # An error report file with more information is saved as hs_err_pid3372.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The log file is posted at the end of the mail. Code: The main program calls connect("COM7"). void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = null; try { portIdentifier = CommPortIdentifier.getPortIdentifier(portName); System.out.println(portIdentifier); } catch (NoSuchPortException e) { System.out.println("Error finding port:"+e.getMessage()); } if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { try { commPort = portIdentifier.open(this.getClass().getName(),20000); System.out.println(commPort); } catch (PortInUseException e) { System.out.println("Error opening commport: "+e.getMessage()); } if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; try { serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e){ System.out.println("Error setting parameters: "+e.getMessage()); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch (IOException e) { System.out.println("Error opening Input and Outputstream: "+e.getMessage()); } if(out!=null && in!= null) { reader = new Thread(new SerialReader(in)); reader.start(); writer = new Thread(new SerialWriter(out)); writer.start(); } } else { System.out.println("Error: not a serial port"); } } } The complete error log file: # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7a74654e, pid=2752, tid=1428 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C 0x7a74654e # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x003a6000): JavaThread "main" [_thread_in_native, id=1428] siginfo: ExceptionCode=0xc0000005, reading address 0x7a74654e Registers: EAX=0xffffffff, EBX=0x6d892aa0, ECX=0x7c80999b, EDX=0x00090608 ESP=0x0090fa00, EBP=0x206e6f76, ESI=0x26970120, EDI=0x003a6000 EIP=0x7a74654e, EFLAGS=0x00010206 Top of Stack: (sp=0x0090fa00) 0x0090fa00: 6b726577 626f7270 656d656c 6966206e 0x0090fa10: 6e65646e 65695320 206e6920 20726564 0x0090fa20: 646e6957 2d73776f 666c6948 0a0d2e65 0x0090fa30: 0000000a 0090fa20 00000000 0090fdc8 0x0090fa40: 00000000 00000000 00000000 00000000 0x0090fa50: 7c3416db 00000022 ffffffff 02b00c98 0x0090fa60: 00000000 00fffff8 0090fd60 6d892bea 0x0090fa70: 0090faa8 73d0e5f4 0090fa88 02dc673e Instructions: (pc=0x7a74654e) 0x7a74653e: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x008c0000,0x00910000), sp=0x0090fa00, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x7a74654e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.open(Ljava/lang/String;)I+0 j gnu.io.RXTXPort.(Ljava/lang/String;)V+114 j gnu.io.RXTXCommDriver.getCommPort(Ljava/lang/String;I)Lgnu/io/CommPort;+78 j gnu.io.CommPortIdentifier.open(Ljava/lang/String;I)Lgnu/io/CommPort;+80 j atconnection.ATServer.connect(Ljava/lang/String;)V+86 j atconnection.ATServer.main([Ljava/lang/String;)V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a6c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1584] 0x02a67c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1016] 0x02a66800 JavaThread "Attach Listener" daemon [_thread_blocked, id=3064] 0x02a65c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3896] 0x02a61400 JavaThread "Finalizer" daemon [_thread_blocked, id=3828] 0x02a5d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1556] =>0x003a6000 JavaThread "main" [_thread_in_native, id=1428] Other Threads: 0x02a5bc00 VMThread [id=3244] 0x02a6e000 WatcherThread [id=2996] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 591K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 66% used [0x22960000, 0x229f3e10, 0x22a40000) from space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) to space 64K, 0% used [0x22a50000, 0x22a50000, 0x22a60000) tenured generation total 4096K, used 0K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 0% used [0x22e40000, 0x22e40000, 0x22e40200, 0x23240000) compacting perm gen total 12288K, used 125K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x2697f6b8, 0x2697f800, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae614a8, 0x2ae61600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a7278, 0x2b7a7400, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 E:\java\jre1.6.0_03\bin\javaw.exe 0x7c910000 - 0x7c9c7000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c906000 C:\WINDOWS\system32\kernel32.dll 0x77da0000 - 0x77e4a000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e50000 - 0x77ee1000 C:\WINDOWS\system32\RPCRT4.dll 0x77d10000 - 0x77da0000 C:\WINDOWS\system32\USER32.dll 0x77ef0000 - 0x77f36000 C:\WINDOWS\system32\GDI32.dll 0x10000000 - 0x10022000 C:\WINDOWS\system32\guard32.dll 0x774b0000 - 0x775ec000 C:\WINDOWS\system32\ole32.dll 0x77be0000 - 0x77c38000 C:\WINDOWS\system32\msvcrt.dll 0x5e160000 - 0x5e168000 C:\WINDOWS\system32\fltLib.dll 0x76300000 - 0x76310000 C:\WINDOWS\system32\winsta.dll 0x597d0000 - 0x59824000 C:\WINDOWS\system32\NETAPI32.dll 0x7c340000 - 0x7c396000 E:\java\jre1.6.0_03\bin\msvcr71.dll 0x6d7c0000 - 0x6da0a000 E:\java\jre1.6.0_03\bin\client\jvm.dll 0x76af0000 - 0x76b1e000 C:\WINDOWS\system32\WINMM.dll 0x6d310000 - 0x6d318000 E:\java\jre1.6.0_03\bin\hpi.dll 0x76bb0000 - 0x76bbb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 E:\java\jre1.6.0_03\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 E:\java\jre1.6.0_03\bin\java.dll 0x6d7b0000 - 0x6d7bf000 E:\java\jre1.6.0_03\bin\zip.dll 0x02dc0000 - 0x02dd2000 E:\java\jre1.6.0_03\bin\rxtxSerial.dll 0x73d00000 - 0x73d27000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=E:\java\workspace\ControllerUnit\lib;E:\java\workspace\ControllerUnit\lib java_command: atconnection.ATServer Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;E:\java\jre1.6.0_03\lib\ext\QTJava.zip PATH=E:\java\jre1.6.0_03\bin\client;E:\java\jre1.6.0_03\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\progra~1\ultrae~1;C:\Programme\MATLAB\R2006a\bin\win32;C:\Programme\VoiceAge\Common;E:\java\jdk1.6.0_03\bin;C:\Programme\Autodesk\Backburner\;C:\Programme\Gemeinsame Dateien\Autodesk Shared\;C:\Programme\QuickTime\QTSystem\ USERNAME=Iske2 OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 6 Model 10 Stepping 0, AuthenticAMD --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 0, cmov, cx8, fxsr, mmx, sse, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 785904k(299012k free), swap 2314444k(1857444k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310 From pl78 at katamail.com Wed Feb 27 09:43:31 2008 From: pl78 at katamail.com (paolo) Date: Wed, 27 Feb 2008 17:43:31 +0100 Subject: [Rxtx] RXTX over USB serial converter Message-ID: <47C59333.5000504@katamail.com> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080227/91e30782/attachment-0011.html From netbeans at gatworks.com Wed Feb 27 10:18:51 2008 From: netbeans at gatworks.com (gat) Date: Wed, 27 Feb 2008 12:18:51 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <47C59B7B.9050800@gatworks.com> I do it, albeit in a limited fashion. The usb GPS receiver that I use can be set to continuously transmit NMEA coordinate/info data. A ttyUSB0 is created, and I get data that way. There are issues. And I suppose that also depends on the device driver ( not the serial-usb driver ) that handles the usb device ( ie what features it has and does not have that supports serial-port functionality.) paolo wrote: > Is possiblle to use RXTX with java application that speack with USB > device by usb-to-serial driver converter ? Bugs ? From drfaygo at gmail.com Wed Feb 27 11:01:35 2008 From: drfaygo at gmail.com (Paul Giblock) Date: Wed, 27 Feb 2008 13:01:35 -0500 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <47C59333.5000504@katamail.com> References: <47C59333.5000504@katamail.com> Message-ID: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> I also use a usb-serial device. No issues except for having to add the usb-serial driver in my kernel config. As gat said, it shows up as /dev/ttyUSBx you may have to mknod if you aren't using udev. -Paul On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > > Is possiblle to use RXTX with java application that speack with USB device > by usb-to-serial driver converter ? Bugs ? > > Thanks > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From oyvind.harboe at zylin.com Wed Feb 27 11:08:38 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 19:08:38 +0100 Subject: [Rxtx] Building rxtx for Win32 Message-ID: Does anyone have any pointers to how to build rxtx for Win32? My favourite environments(in order): - Debian cross build. rxtx-devel/buildwin32 seems to be a bit dated and I only speak Debian Linux with any fluency. - Cygwin based build. - MinGW. I was able to install MSYS without trouble a couple of years ago, but I can't find that straightforward installer anymore. We're seing SEGFAULTs w/rxtx under Windows using the latest (???) version and I would like to have a stab at tracking down the problem. http://users.frii.com/jarvi/rxtx/download.html -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From oyvind.harboe at zylin.com Wed Feb 27 13:57:42 2008 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind_Harboe?=) Date: Wed, 27 Feb 2008 21:57:42 +0100 Subject: [Rxtx] Building rxtx for Win32 In-Reply-To: References: Message-ID: (Clearly this was for the list :-) On Wed, Feb 27, 2008 at 9:21 PM, Beat Arnet wrote: > Hi, > You might find this useful: > > http://www.codeskin.com/c2oooProg_faq.html#rxtx > > http://www.codeskin.com/pubsvn/rxtx/tags/rxtx-2.1-7r2-DTR-patch/Makefile Thanks!!! It works :-) I'll have to take the actual build result for a spin tomorrow. Why isn't this part of the "official" rxtx repository? -- ?yvind Harboe http://www.zylin.com - eCos ARM & FPGA developer kit From ljmiller at sdsc.edu Wed Feb 27 14:37:11 2008 From: ljmiller at sdsc.edu (Lawrence J. Miller) Date: Wed, 27 Feb 2008 13:37:11 -0800 Subject: [Rxtx] rxtx can't find prolific usbToSerial under windows Message-ID: My Java program that uses rxtx does not find com ports that have been added to a windows system with a Prolific usb dongle. The ports show up in device manager, and other win32 apps. My program is a command- line and runs in Java under cmd.exe. My program does find COM1, which is on the system motherboard. Does anyone have any ideas on how to get rxtx to find those additional com ports? From mirek at host.sk Wed Feb 27 15:53:13 2008 From: mirek at host.sk (mirek) Date: Wed, 27 Feb 2008 23:53:13 +0100 Subject: [Rxtx] RXTX over USB serial converter In-Reply-To: <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> References: <47C59333.5000504@katamail.com> <748d0ca90802271001s6e5c07e7v69a1ef5035bd42e8@mail.gmail.com> Message-ID: <47C5E9D9.9030004@host.sk> hello can you give me some howto, how to create a /dev/ttyUSBx device? i am very interesting in this, because i cannot make my usb-serial device running in java using rxtx :-( mirek Paul Giblock wrote: > I also use a usb-serial device. No issues except for having to add > the usb-serial driver in my kernel config. As gat said, it shows up > as /dev/ttyUSBx you may have to mknod if you aren't using udev. > > -Paul > > On Wed, Feb 27, 2008 at 11:43 AM, paolo wrote: > >> Is possiblle to use RXTX with java application that speack with USB device >> by usb-to-serial driver converter ? Bugs ? >> >> Thanks >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- e-mail: mirek[[at]]cnl.tuke.sk jabber: mirek[[at]]jabbim.sk homepage: http://www.cnl.tuke.sk/~mirek english: Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html slovak: prosim, neposielajte mi prilohy vo forma